I want to slowly migrate an existing app from Blaze to React. The Blaze app is based on FlowRouter, and I saw in the Meteor guide that FlowRouter can be used in combination with React, too.
But after digging deeper, I saw that this recommended solution is based on a package created by Arunoda, react-mounter. As most of his packages, this npm package seems to be abandoned. The last code change is from April 2015. So this is probably not a good “going-forward solution”.
Is there another option besides switching the whole app to React Router, which would require a lot of refactoring? I mean, is there a community-led project that could replace react-mounter?
1 Like
The last code change is from April 2015. So this is probably not a good “going-forward solution”.
Why not? If it works in your app today, it should work tomorrow. We are using IronRouter still although it’s been “abandoned” long ago. We use many abandoned packages, like autoform. I wouldn’t worry about it.People could stop maintaining any package at any time, but who cares? These packages don’t go bad like fish.
According to @sashko the only reason why FlowRouter (or any package) would break post-Meteor v1.0 would be a bug in a new version of Meteor.
Almost every single breaking change since Meteor 1.0 is a bug (except some issues with build plugins). The best thing you can do to ensure this keeps working is stay up to date with the newest versions, and test out the beta releases and file bugs when things stop working for you.
3 Likes
Well, I’ve heard these arguments a lot, but they are simple not true. When I upgraded my 1.2 app to 1.5 just recently, it took me about 3 weeks to get the app up and running. Most of these problems were caused by incompatibilities in the build plugins (which sashko already mentions in his brackets), but there were also a couple of breaking changes. For instance, I had to replace Arunoda’s streaming package with RocketChat’s alternative. Seems as if Arunoda had used some hacks that were not possible since Meteor 1.3 anymore. After these experience (which were quite similar when upgrading from 1.1 to 1.2), I lost my trust in unmaintained packages, and also in the statements of MDG like those you cited. I have to admit, though, that the upgrade from 1.3 to 1.4 and 1.5 was much easier. Yet, I’m still facing a big problem with 1.5.1, where I am trying to create a reproduction repo abernix is waiting for.
2 Likes
I see. I guess there are some exceptions, especially for packages which rely on unofficial api. But maybe the worst of it is behind you. I think there is greater value in using something now which may never break, than in making it a priority to replace it now just in case–which might never be necessary.
In our case we really use a ton of old packages. This app has been in production pre-1.0 and we had to update things a lot more back then, but post 1.0 there haven’t been a lot of big challenges. So we’ve gotten a lot of value out of these packages, which allowed us to use our time to make our product better for our customers, instead of doing regression work to replace things just because they aren’t maintained.
Often if something breaks in a package used by many, someone in the community will fix it.
some of the package we use
# Core packages
# =======================================
less@2.7.9
accounts-password@1.3.5
accounts-ui@1.1.9
email@1.2.0
http@1.2.12
reactive-var@1.0.11
reactive-dict@1.1.8
amplify
random@1.0.10
force-ssl@1.0.14
ecmascript@0.7.2
promise@0.8.8
react-meteor-data
react-template-helper
mdg:validated-method
# Community packages
# =======================================
practicalmeteor:mocha
matb33:collection-hooks
cottz:iron-query
#zimme:select2-bootstrap3-css
aldeed:autoform-select2
yogiben:autoform-tags
aldeed:autoform
aldeed:collection2
meteorhacks:npm
vsivsi:job-collection
iron:router
manuel:reactivearray
fourseven:scss@3.8.0_1
# Required for Homer theme
twbs:bootstrap
fortawesome:fontawesome
zimme:iron-router-active
natestrauser:animate-css
# okgrow:iron-router-autoscroll
kevohagan:sweetalert
chrismbeckett:toastr
maxkferg:bitly
#========
meteorhacks:zones
cmather:handlebars-server@2.0.0
msgfmt:core@2.0.0-preview.12
msgfmt:extract@2.0.0-preview.9
msgfmt:ui-dev-only
cwohlman:pickadate@1.0.0
momentjs:moment
sacha:spin
mousetrap:mousetrap
pfafman:font-awesome-4
raix:handlebar-helpers
meteorhacks:ssr
peppelg:bootstrap-3-modal
konecty:mongo-counter
tmeasday:publish-counts
useraccounts:bootstrap
manuel:viewmodel@1.9.15
percolatestudio:segment.io@=2.0.0_1
wylio:mandrill
edgee:slingshot
# Cron package
percolate:synced-cron
# Anti packages
# =======================================
anti:modals@0.4.0
anti:fake
# Our atmosphere packages
# =======================================
whiterabbit:tokyo-mitsubishi-ufj-spot-rates@0.2.0
# Our local packages
# =======================================
# We want these instantiated ahead of our other packages
wrj:log
whiterabbit:adhoc-packages
whiterabbit:blackship-fulfillment
whiterabbit:order-fulfillment
whiterabbit:shopify-orders-processing
usefulio:open-exchange-rates@0.1.2
cheerio
whiterabbit:shared
whiterabbit:statemachine
whiterabbit:helpscout
whiterabbit:stripe
whiterabbit:saasu
#whiterabbit:japanshippingrates
whiterabbit:japanpost
#whiterabbit:japanpostreportpdf
whiterabbit:s3functions
whiterabbit:jspath
#whiterabbit:select2
whiterabbit:subscription-manager
whiterabbit:chartist-tooltip
whiterabbit:bootstrap-datepicker
whiterabbit:parcel-rest #should come after shopify-orders-processing
whiterabbit:string-humanize
whiterabbit:searchindices
whiterabbit:fixtures #debug only
#whiterabbit:capture-webpage
whiterabbit:wre-products
whiterabbit:cloudinary
whiterabbit:referral-payout
whiterabbit:package-forwarding
#useful
npm-container
msavin:mongol
zeroasterisk:throttle
zeroasterisk:throttle-accounts
#sanjo:jasmine
#velocity:html-reporter
meteor-base@1.0.4
mobile-experience@1.0.4
mongo@1.1.16
blaze-html-templates@1.0.4
session@1.1.7
jquery@1.11.10
tracker@1.1.2
logging@1.1.17
reload@1.1.11
ejson@1.0.13
spacebars@1.0.12
check@1.2.5
shell-server
standard-minifier-css
standard-minifier-js
# Meteor's kadira replacement
mdg:meteor-apm-agent
2 Likes
I agree 
And I see you’re also following a package-based structure for your app. I like this approach, especially when it gets to re-using packages across apps.
1 Like
That’s doesn’t look like a package-based approach to me, it looks like a monster conglomerate app full of things waiting to break.
2 Likes
Yeah. But wasn’t this one of the main USPs pushed by MDG for a long time? I mean, being able to use a lot of ready-made packages? I remember that quite a while ago skinnygeek mentioned that he tries to avoid community packages as much as possible. At that time, I didn’t really get why. Now I know.
This reflects more of the MDG problem. Like why would they let the most productive person in the community slip away from them? Big heads with only one vision… follow the props.
MDG is so wrapped up in themselves and Thursday night bar volleyball that they do not have time to see the world around them.
Anywho, so many of these packages are like 30 lines that it does not make much sense to even use them at all since it takes more time to look for, read about, wonder about, learn functionality, test for functionality hoping it hasn’t broken lately and wasted your time, and then put into your code than it does to write 30 lines.
Wonder why Meteor doesn’t have an internal router? Hm. Probably cause Arunoda did it so they didn’t have to. Probably something they should have as it is approximately as integral to a modern app as a user account system is.
2 Likes
We aren’t going to see any kind of progression in dead packages - in kadira:FlowRouter we’ll never see proper server side rendering for example. There is an active fork though:
I had a closer look at VeliovGroup/flow-router and am a bit disappointed. Although I am happy that someone picked up Arunoda’s work, this fork is very tightly coupled with Blaze only, without proper React support.
They even included template helpers and the layouting code that once was separate, like BlazeLayout and the flowrouter-template-helpers. I don’t think this is a good going-forward approach. As it is now, it’s a strange mix of the old IronRouter, the original FlowRouter and a couple of packages that - at least IMHO - do not belong in a router package.
I would prefer a router that was focusing on routing only and let you easily swap out the layouting engines. For my migration task, the old FlowRouter seems even better than this fork. I am even thinking about making a complete switch to ReactRouter now, but this would mean that I would have to refactor a lot of my existing code base, and I would also lose the possibility to share some of my private packages with apps that are still using FlowRouter.
It’s a shame that MDG doesn’t provide carefully designed routers themselves (or at least make sure that there’s a really good alternative for all the view layers they officially support).
I was going to ask this . WHY METEOR DONT HAVE ITS OWN ROUTER ,Before I saw this . Iron router specifically renders with meteors blaze . wTF
They shouldn’t have brought react here ! Prolly wanted more people to install Meteor
1 Like
we are earning millions in revenue with iron router. Just make it work. Done is better than perfect.
2 Likes
Think of the entire Node/NPM/Meteor ecosystem as Slackware circa 1998. Give it another decade and things will be more like using Android.
React sucks anyway, use Blaze.
If you’re earning millions in revenue with Iron Router I will gladly write you a replacement.
Well, I am using React in some of my side-projects and like it. But integrating it into an existing Blaze app sounded way easier than it actually is. The router is only one part of the story. Yesterday I stumbled upon the problem that tap:i18n doesn’t support React, nor does useraccounts. Of courses, there are alternatives for both, but in this case you have to double your code for the same task unless you do a full transform. Not nice. I’m actually thinking of keeping Blaze for now, but I know that’s a dead-end, so I thought I might gradually migrate.
Why is Blaze a dead-end? Has the project been terminated? Blaze is the shit in my book, and React is just a bunch of vocabulary and crap on top of some pretty standard techniques… namely using the dreaded globals. Everyone tells you not to use them…and everyone tends to be the people using them but obscuring that fact so that you think they are cool and tricky because you could only do what they do if you used globals.
Look at all the (dead) Blaze-related Atmosphere packages, and you know why it is in decline. There is so many package where the authors don’t even bother to answer to issues or accept PRs.
But I agree with React. It’s a pretty weird technology. It has very good basic concepts, but the biggest problem is that they tend to break them with stupid stuff like contexts. And it is so verbose that it leads to a mass of boilerplate. Let alone overcomplicated stuff like HOCs, which makes code quite unreadable.
Contexts? Isn’t that what the whole thing was supposed to avoid? lol
Blaze is/was the bomb. Perfect for Meteor’s intent. But like I said…they want to chase everyone else’s shiny objects so they can keep the super trendy hipsters blogging about them. I guess they forgot that Meteor used to be its own shiny object.
1 Like