For those of you who have transitioned to using Flow Router instead of Iron Router, what are your impressions? What were some challenging points in switching (i.e. breaking old habits)? What do you love about Flow Router?
I’m considering switching soon, next time I start a new project. Unfortunately there are so many great packages that don’t work with Flow, such as manuelschoebel:ms-seo, Orion, and tons more.
There are some forks of all the apps you mentioned in Atmposphere for flow.
There are some other packages which natively support Flow and IR both.
I know it’s kind a primitive at this stage. But there will be more soon.
Awesome, very helpful! Looking forward to diving into Flow Router and learning it soon. 
This package is good, too: https://github.com/arillo/meteor-flow-router-helpers/
It includes the active-route package Arunoda mentioned above, and also has other useful stuff such as an iron-router-like pathFor helper.
I like flow router, but I am still not 100% sure which patterns to use, what put where etc 
But for me it was nice transition to migrate controllers to kinda route groups triggers.
And doing just simple subscribe in flow-router than rendering layout in which I wait for subscription to be ready and than rendering/calling actual UI templates with custom helpers ( which feed them “data”) as template parameters instead of providing that like in iron-router directly from router.
I first hardcoded “data” in end templates, but now i am trying to feed it to them by custom helpers in parent layout, to reuse same UI template for various data inputs.
So it does not redraw every time 1 of these subscriptions become ready (we all remember iron-router for that ), but every template nicely wait for it’s own subscription.
I like how it is handled now …
Still this feels really native for me now when working with Blaze templates and flow router.
We also plan to switch to React soon, still studying how to put all these principles together.
If we are going to switch various components to React and still use that Blaze flow model with updates coming from all directions what does not sounds very good to me, or we somehow start to use Flux like store to put all those interactions to 1 place. I am not exactly sure if it can be done easily per template/component, but it seems possible to rewrite 1 component a time. With having flux state and standard Blaze changes both at same time and just switching components between these 2 systems. Till Blaze would be no more needed.
That is the information I am looking for, maybe @SkinnyGeek1010, @arunoda or some1 else from kadira team could put together short blog explaining these meta patterns they took to migrate.
As for me it feels kinda high level of abstraction is needed for such migration and I am not sure if the end state I am looking for is the right one.
It would be nice to hear from some1 else where is that sweet spot, or best way to approach this and order in which these little steps should be taken to end up with nicely maintainable system.
So worth the hassle. If you’re going to do the refactoring make sure you subscribe to data in templates… unless you need FastRender support today then in that case you have to use the router subs. In FlowRouter 3.0 you won’t be able to subscribe in the router anymore (which i’m excited about) so you might as well plan ahead if possible.
If you can leave FlowRouter to just do… routing, the better off you’ll be. Let something else in your app take care of other concerns when possible.
IR is bloated, complex, and in my experience buggy. The reactive problems seal the deal.
Dealing with packages that aren’t compatible will be annoying at best. You can likely fork it and re-wire it for FlowRouter though. IMHO the packages should have abstracted all of the logic so that there was a thin facade adapter for IR and then they could have made another thin facade for FlowRouter… etc… I think Kadira has something for setting head tags too.
Migrating a current project slowly can be done by moving re-running logic out of the router so that it’s not doing much besides routing. Then when this is all done it makes it much easier to just switch.
Yep i’m doing this right now actually. As one part of the app has a bug or needs a new feature I copy/paste the blaze template into JSX, run a find/replace on className, stub out any template helpers then get a basic React unit test passing. Then re-wire as needed. Usually this means adding to a flux store or watching a new collection to get the data. Tab triggers to spit out boilerplate for this is must have. This is one of my favorites for Refactoring into React: https://www.youtube.com/watch?v=BF58ZJ1ZQxY
As far as Meteor specific things are concerned… my goto strategy is to start out with Reaktor (React facade for FlowRouter), and have a thin React ‘shell’ for each page. This shell page would just basically render a <BlazeTemplate tmpl={Template.about}/> component. This allows you to use Reaktor and still keep your Blaze pages.
If you are using IR link helpers you’ll need to find/replace as you drop in each page. Doing this for 15 pages only took an hour, including writing a BlazeTemplate component. I also didn’t have much on the filters besides authentication and analytics tracking. This was easily ported with FR triggers.
Then each page gets converted to React eventually as needed. It’s a client app so it has to be done when there’s changes or solves a problem (or bugs). I’m also still using Blaze for things like the Tabular tables package.
Hmmm, are you looking for more the above? Or general react info like the video link? From Blaze to React or Iron Router to Flow Router?
I would also highly suggest tinkering with the open source apps to get a feel what you’re end result will be (most likely it will be different form that).
I’m also using a completely different setup for a new project that’s using react-router and webpack with react-hot-loader (reload per function to retain state), real ES6 modules, and NPM integration. At it’s current state it’s more like a fussy Lamborghini 
I’ll have more to post on this setup soon!
Useraccounts packages are now (from v1.12.0) also router agnostic other than UI framework agnostic…
But routes configuration is still super easy: lets have a look at useraccounts:flow-routing and also at useraccounts:iron-routing.
So, now, the choice for the router is up to developer!
…at least from the useraccounts point of view 
Side note: how have I not heard of useraccounts?? I thought Meteor’s built-in account packages were all I needed.
I am moving to flow router. One thing I cannot work out is how to get data in a helper… this.dataItem used to work… now I cannot find out where to get the data, what is the context?
Template.currentData() ?
That produces an Object but not of the data in the current template. this. was so useful.
Personally I kind of like FlowRouter better. Nothing against IronRouter, but FlowRouter just feels more intuitive. It has a lot of really “oo, that’s nice!” kind of features
I tested this and it works great.
FlowRouter.route('/test/:id', {
action: function (params) {
BlazeLayout.render('test', {id: params.id});
}
});
<template name="test">
The ID is {{id}}
</template>
I’ve been developing over last year or so with IronRouter, and it worked well so far (I am not using subscriptions in the router itself, but instead follow the typical guidelines of flow router but in the iron router). So now I am on a state of development when need to decide on a ‘final’ production solution. And the very first thing I noticed with Flow Router is that it does not have a good documentation and lacks some basic thing, for example - I could not find anywhere how to retrieve a hash parameter? Or am I looking in a wrong place? I will most likely end up with Iron Router and stuck on the version of meteor/packages that support it. Really getting sick with all this overhype of trying to improve things that already are great by removing features… :-/
FlowRouter.current().context.hash. I’ve found the documentation to be fine. FlowRouter.current() is documented, and if you just dump out via console.log and explore the returned object, you can see all kinds of useful stuff.
Thank you @ffxsam. I will check it again then. Sorry for a bit harsh comment above. I do want to stay consistent with the Guide, it is just things are changing rather fast… 
Btw, regarding the hash I have found 2 issues here which seem to be confusing:
Could please someone with experience in Flow Router confirm that one can actually set the hash as well, not only get it? Or the complete path/url should be set, that includes the hash?
So, aside of fundamental discussions going on here (future, roadmaps, how good react is, and how bad meteor is ), please let me (the humble guy who just want to do the job) turn back the discussion to a bit more grounded questions, in particular regarding the actual usage of FlowRouter and BlazeLayout (I’ve been migrating over last 2 days, but there seem to be a bug).
My app layout structure is following:
Layout_first > Layout_second > Template.dynamic template=somename
And then I have another separate layout to show, let’s call it Layout_somename.
In the FlowRouter action I put something like:
BlazeLayout.render('Layout_first', {somename: 'Layout_somename'});
This thing throws me an error:
[Log] Exception from Tracker recompute function: (meteor.js, line 930)
[Log] NotFoundError: NotFoundError: DOM Exception 8 (meteor.js, line 930)
And this error can be fixed only if I remove the Layout_second, and put the Template.dynamic right into the Layout_first, which I don’t want to do. Any ideas, solutions?
I wonder if anyone can help here? C’mon guys! That should be simple for you!
Alright, I just spent some time playing with FlowRouter and React, considering migration from my current IronRouter/Blaze setup, as I had to decide a ‘final production’ approach… My humble conclusion is that I would like to stay with Blaze and IronRouter.
Reasons:
The app that I build does not have much of components, but those that it actually has, rely heavily on DOM manipulating libraries and jQuery… I don’t have time to rewrite all them into React ‘super cool’ components… And the currently existing libraries for React can not be compared in functionality with existing dom manipulating libraries. I care mostly on user experience but not speed of computations on a client computer.
I do already follow the pattern of ‘reusable components’ and templates subscriptions with my templates, and so far the whole structure looks very logical and separated from each other. I can easily ‘disable’ a component by just commenting a template that it creates. At this moment I hardly can imagine any spaghetti code and uncontrolled re-rendering, that seem to be the biggest fear of all the Blaze users…
In current state FlowRouter seem to be weaker than IronRouter. In particular it does not allow me to have proper nested dynamic templates… And as I understand that in general it is more focused on React, most likely it will never have those improvements. And I will not break my super smooth structure because FlowRouter can not handle nested templates properly.
Writing ‘html’ in jsx and then compile it to ‘something’ that only React can read, looks very, very wrong.
The only two things that I liked in React are props validations and much richer events map than one on Blaze… I wish we improve there with time.
I see that there are many users that still use Blaze, so I just hope that if we encounter any security issues with Blaze and IronRouter we will be able together to solve it. Peace. 
Not sure if I’m missing something, but if you’re talking about something like the following, FlowRouter can do nested dynamic templates:
<template name="layout">
{{> Template.dynamic template=content}}
</template>
<template name="post">
{{> Template.dynamic template=left}}
{{> Template.dynamic template=right}}
</template>
<template name="article">
<!-- article content -->
</template>
<template name="menu">
<!-- menu content -->
</template>
FlowRouter.route('/post/:postId', {
name: 'post',
action: function () {
BlazeLayout.render('layout', {
content: 'post',
left: 'menu',
right: 'article'
});
}
});