HMMM… that sounds mighty fine to me, actually. Way more simple!
I’m confused by people claiming that lack of reactivity in the router and the ability to update things in a template as they load is a major selling point in flow router versus iron router. It seems to me that iron router can do those same things too.
If you want things to appear as subscriptions load, then use the subscriptions hook instead of waitOn in Iron router.
If you don’t want things to reactively rerun routes in iron router, then either don’t use reactive variables in the routes, or use the onRun hook to only run things once, or use a template’s onCreated or onRendered hooks to do it at the template level.
Depends on what you want to achieve. For example, if you need to run a process exactly once when a router is run, it is kind of tricky with iron router (although achievable). There are other scenarios where you’ll want to control reactivity.
But again, as @wallslide has also pointed out, iron router is also capable of doing that, only with some extra work which defaults don’t provide.
Furthermore, iron router is more like a full-featured meteor app development framework where you can basically design the whole app within the router namespace. I’ll leave it up to you to decide if that’s a good thing or a bad thing.
In the end, everyone has different preferences and both routers have merit. Both Arunoda and Chris are great devs with enormous contributions to the Meteor ecosystem.
We should be glad we get to choose 
1 Like
Hi @serkandurusoy,
Like @wallslide I too am a bit confused by Flow router’s claimed differences with iron router.
I think that’s a bit misleading. It’s not extra work at all. waitOn is one option; subscriptions is another.
It’s just a different hook. Literally you do this:
Router.route('/post/:_id', {
subscriptions: function() {
// returning a subscription handle or an array of subscription handles
// adds them to the wait list.
return Meteor.subscribe('item', this.params._id);
},
instead of this
Router.route('/post/:_id', {
// this template will be rendered until the subscriptions are ready
loadingTemplate: 'loading',
waitOn: function () {
// return one handle, a function, or an array
return Meteor.subscribe('post', this.params._id);
},
So I think Flowrouter offers no advantage here.
Also in the Flow router doc it claims
In Iron Router you can use reactive content inside the router, but any hook or method can re-run in unpredictable manner.
but isn’t that too a non-issue? from iron-router guide:
onRun: Called when the route is first run. It is not called again if the route reruns because of a computation invalidation. This makes it a good candidate for things like analytics where you want be sure the hook only runs once. Note that this hook won’t run again if the route is reloaded via hot code push.
1 Like
You are actually correct, but the problem is the collective
intelligence that’s built around iron router which provides almost
exlusive examples, blog posts, tutorials, boilerplates and example/open
apps all built around the paradigm that starts reactivity on the router
level.
So a typical meteor developer worklow would generally consists of
stripping reactivity off of iron router to achieve the out-of-box
behaviour of flow router.
Also, I’ve had my share of frustration with onRun running multiple
times (twice to be exact) on occasion. It was not a bug per se, but a
kind of misleading lack of proper information around non-reactive route
handling.
All that being said, I’m still exclusively using iron router mainly
because it is mainstream which makes me feel confident I’d be able to
find aid to overcome any problem. Yes, there are outstanding bugs and
feature requests, but non seem to have been a showstopper for me, yet.
But I am kind of eyeing flow router as well. And the main reasons being
its:
- recency: built upon an experience in routing with meteor so there is
no technical debt. (iron router had to discover a lot of things from
scratch) - developer: arunoda (just like chris) is a great dev whose package
sources I don’t feel obliged to read before getting into my apps
Again, great to have freedom of choice
2 Likes
Guys let me jump in: @wallslide @maxhodges
Biggest feature of Flow Router is it don’t take the control of the application. With it’s rendering decoupling and it’s reactive APIs, developers can structure his app as he wanted.
For an example, with Flow it’s pretty easy to build custom loading sections in your app. We’ve built in APIs for that.
And we’ve used a fewer amount of code in the router and it never re-runs. Because of that, we can save unwanted CPU cycles. That’s very important for mobile apps.
FR got quite nice API and I’m happy if someone could implement it on IR.
We are not fighting with IR. What we try to show is another way to structure Meteor apps.
3 Likes
The only problem with flow-router I’ve found (and it’s not even a fault of flow-router) is that so many third party libraries instantly assume you will use iron:router
1 Like
That’s hopefully going to change and we’ll see quality packages around both, even those that support both!
For example, there’s already this one with 177 downloads:
1 Like
@arunoda, Not being familiar with flow router myself aside from reading over the docs, I’m still trying to understand where flow router is offering advantages over iron router, and where it is just doing things differently. It sounds like rendering decoupling is a big plus if you are developing with something other than Blaze.
Using iron router, if I want a giant loading screen until certain subscriptions are loaded, then I could put those subscriptions in waitOn. If I had subscriptions that I don’t want to block the route, I’d instead put them in subscriptions, and then I could either just let the data load in, or I could hide portions of my templates by only displaying them when the reactive Router.current().ready() became true.
In this way I can easily build custom loading sections with iron router. How does that compare with how flow router works?
That’s because we only had one router earlier. Developers and authors will find patterns to work with these.
For an example, useraccounts will support both IR and FR. Or may be some other router we will seen in next month or after.
see: https://github.com/meteor-useraccounts/core/issues/308#issuecomment-83409225
It’s very important for Blaze as well. Then, you can think beyond yeilding templates. (which I never understood correctly) and define your layouts as you like.
Router.current().ready() is kind a bad. It’ll re-run for any change in your router. For an example, let’s say subscriptions loaded correctlly and you are appending some query param. Then all the helpers for Router.current().ready() is calling again. Which leads to some more CPU cycles. If you are using mini-mongo APIs inside the helpers using Router.current().ready() then that’s pretty heavy.
We are not only decoupled, but also provided a rich API to get the data from the router reactively in performance in mind. Above is just one example.
I don’t say it’s possible to do what we claim in Flow Router. We make it first class and give all the support we could from the router.
+1 for Flow Router
Ran into one bug (will get an issue up when I get a chance) but find it so much easier to reason about and love that the whole page does not re-render, flows (get it) well with a component based set up. eg. the NAV component may have some subscriptions (maybe most recently viewed posts by currently logged in users) and if the current post changes, that NAV component should not have to re-render, redo anything because only the main ‘postView’ component has changed.
I think that having the router separate from the renderer (while a little confusing at first) did make a lot of sense, plus I found that for prototyping, I would have to set up so much boilerplate to install Iron Router, where as I can start with flow router and add the layout stuff a bit later.
Minor downside; not as many integrations with existing packages, but that can be managed.
Thanks @arunoda for your incredible hard work on this, and Chris on his work with Iron Router.
BTW: I’m not the only one working with Flow Router. Initial our meteorhacks started working. Now, a lot of people started contributing.
I specially need to thank @delgermurun for implementing key features.
3 Likes
Ive read a couple responses that note there might be issues with iron router when using Jade. Is this true, and if so, why? Ive yet to use either of these routers but I like my Jade.
I’ve been using iron:router along with mquandalle:jade for several months and I’ve yet to run into any issues. I’ve also played with FlowRouter for a bit now and no issues between it and Jade either
1 Like
@arunoda Is there a way to do an action before leaving a route in Flow Router, like onStop hook does in Iron Router?
I would like to change to Flow Router but I need a way to detect if data has changed before leaving a route.
Thanks
Could you use a template’s onDestroyed hook to accomplish that?
It’s in the developing the right now. We have an active PR.
Hi,
I am a newbie and don’t know why but when i started creating new meteor project… it was all in total of 400MB including .meteor directory… but now after a week, installing a few packages (.meteor) directory filesize has been increased upto 4GB… WebStorm starts hanging up always… will you guys help me out with this thing ???