Just curious on why the community has moved to Flow Router from Iron Router? Is it because it relies on Blaze?
My guess is because it was trying to do a bit too much and people abused it. People were putting data loading logic at the router and it turns out that it’s better to decouple that logic from the routing and place it closer to the page and components consuming it, so Flow Router came focusing only on routing thus enforcing better practices.
That’s my subjective opinion, I use react router so others will keep me honest here.
7 Likes
Apparently caused templates rerunning much
Mainly because is cleaner, focuses only on routing and has better design decisions.
But, honestly, I currently would just stay away from both (all my recent projects are in react and use react-router and I’m quite happy with it, even with the continuous API changes), original flow-router is dead and the extra fork added the wait on subscription, data hooks etc etc, which are some of the worst design decisions they could have taken since they are recreating iron-router on top of flow router.
1 Like
Making hello world is also awesome design decision. How is navigation guard (wait on subscription), not a standard feature anyway?
1 Like
It simply should not be handled at the route level.
A router should only do routing, data subscriptions, waiting etc etc should be done on the component level.
There is a reason SRP is a thing in coding.
Less dependencies, much easier refactoring if needed, cleaner design etc etc.
And when you {{data.key.key.key}}, you hope that the keys get available before component loads?
I would argue that if you’re writing {{data.key.key.key}} you may already want to refactor, but anyway, don’t load that template until you have the data ready.
Sure, it’s more code, but it lets you easily remove the router (since it would be doing only routing) or reuse the component.
Quick example here, you subscribe in the template and use {{Template.subscriptionsReady}} to “wait” until the data is available.
1 Like
Vue doesn’t have that, and even then subscription ready fails with their router guard :D. I remember the selling point of flow router was that it wasn’t blaze exclusive, so that you could basically write recursive react render functions for that data.key.key.key since you can’t use “if” anyhow so all these nice practices and such, are not merely for the sake of composability.
PS I can’t help thinking I should pick the pagination package that is iron router based as it is in fact aware of what data wherever, even if I’d have to basically run it into vue and have it out as vue, too.
Never used Vue myself, but I’m pretty sure that the vue guys can give you good patterns for handling data subscriptions.
I honestly also fail to understand how you would end up with data.key.key.key in React if you have designed your components in a sensible way.
Seems like you are trying to solve with packages problems you have created yourself.
Doesn’t sound like a good idea to me but to each his own.
Vue-meteor-tracker Has a $subReady feature, so you can easily wait for subs and display a loading screen 
Used cache package method with guard since that’s the only way to have vue not break if you reference nested object key from DDP. Akryum himself featured cache compatibility in readme. I should try running non-global ready hook in non global guard :P.
There’s a section in meteor guide that explains: you may as well just avoid segmented pagination, yet alethes/meteor-pages even populates neighboring subscriptions.
Well, at least to me Arunoda’s argumentation on the design flaws of IronRouter were plausible and thus convincing. However, now that he left the community and his packages are more or less dead, I would switch over to ReactRouter instead.
More than that the part about rerendering was made years ago, although there’re still recent posts describing this as something that can’t go away.
Here’s the solution 
import get from 'lodash/get'
Vue.filter('get', (obj, path= '') => get(obj, path) )
<span>{{ data | get('key.key.key') }}</span>
1 Like