Hmm, turns out this became a wall of text… TLDR: Switch to Flow Router, I don’t know how long we will be waiting, or if we ever will, get a core router.
Having just done this, I can hand on heart say do the switch. It’s taken me a little while, but it has been entirely worth it.
The first issues we had with Iron Router were routes ending up being too reactive, and things started happening and we couldn’t debug as to why (onBeforeAction running twice no matter how far back through our code base I looked, and similar issues). I want to stress that Iron Router was not the only cause of issue in our code base, but moving away from it allowed us to cut out a lot of the other issues which were a result of doing things in the wrong places because we could, and we were learning Meteor and what is “best practise”.
Through the first couple of months of development for our application, Iron Router seemed like a great choice (probably because it was the only real choice for getting us up and running quickly). It quickly became apparent that it was doing too much for our needs, and in researching further, we found that Flow Router was a much better fit for what we need, something clean, simple and well scoped, that knows it’s responsibilities and it’s limitations.
I’ve found that switching between the two involved some rethinking of responsibility in terms of what code lives where, and while routes can have subscriptions, we have tended not to use them. I only see them being used in instances where I need to subscribe to something for a route, which is based upon the userId only. Everything else lives in a subscription managed by it’s own library, or in the template calling it. This shift, to using Template level subscriptions has allowed me to clean up the code, and work towards a semi-component-isation of the code.
The summary of what we did for each route are as follows:
- Move
onBeforeAction to main template’s onCreated
- Use Flow Router’s
action function purely for telling FlowLayout what to render
- Move
onAfterAction to main template’s onRendered
- Place the subscriptions in a template level
this.autorun function if they require reactivity
- Create helpers to replace the Route’s
data function
Over all I feel that this has given us a cleaner code base, better separation of concerns, and some happier developers.
In addition to this I am have not seen enough detail on an MDG implemented Router to be able to say whether it be a good idea to wait. I think it would be very unlikely as @SkinnyGeek1010 stated. Further to that, the last thing I read on it was a post by Chris Mather stating he would be looking into getting something in as a core. My feelings toward this are that Iron Router is trying to do too much, and I think it would not be good to have IR or something as reactive as it in as a core router. I feel the approach and ideology of Flow Router is much more conducive to well written applications, as it allows the developers, new and old, to focus their code and be clear with what they are doing and why.
instead
!