Iron-router becoming incompatible. Switch to flow-router or wait for MDG router?

I’ve noticed that some things with iron-router in conclusion with some packages don’t work anymore, I guess this has to do with it not being maintained very actively anymore. I guess flow-router is the router that’s currently being actively maintained and I think there’s version 2.0 soon.

I’m not sure what to do right now, stick with iron-router, switch to flow-router or wait for the router in core. Do we already know when the core routing will be implemented? I’m guessing for 1.2 which is probably at least 2 more months away?

2 Likes

I highly doubt 1.2 will bring a new MDG router, is this something that’s announced? I would just use whats available now. In my experience waiting for the perfect solution is a great way to miss out.

FlowRouter is on the brink of 2.0 and the current readme uses 2.0 syntax. Also FlowRouter 3.0 is in the works (and experimental) which provides server-side rendering with React.

3 Likes

Last I checked there was some friendly debate over whether or not routing should be in core…my feeling is that we will instead have a few router packages to choose from, such as iron and flow and whatever wonderful thing happens next :slight_smile: instead

A core router would be a major update and it would probably have been listed on the 1.2 release notes, but I could be wrong.

I think you should switch to flow router.

16 Likes

+1 for the clarity :- )

2 Likes

For those curious, in the what’s coming in 1.2, there is a section for post 1.2 features and they mention that routing is one of then:

Building up the stack. We’ll be pulling features such as routing into core and taking a more opinionated stance on how to structure large Meteor apps.

1 Like

That’s exactly what I was referring to. Well, I have an assumption what is going to happen with routing in the future. I am guessing one of the best routing packages out there will make it into core.

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.

10 Likes

If I’m reading it correctly the router is under the “considering the road ahead”(eg not in 1.2) with SQL and es6 modules.

Agreed. And while I’m probably adding 0.1 and 0.2 and getting 0.30000000000000004 (JS joke), I wonder if @sashko’s recommendation is a hint that Flow Router will make it into core.

1 Like

FlowRouter has a very low learning curve, and is quite intuitive to use. I would say it’s actually much easier than iron router. There’s only one caveat: some packages still work on the assumption that you are using iron router. Check this ahead of time. If there are no conflicts, definitely switch to flow-router, it’s great.

2 Likes

Submitted ticket in Issues 9 days ago no one replied and there are a lot of unanswered questions there ( no answers on tickets for 15 days). So i guess maintainers work for something else.

I’ve just switched out iron router with flow router. It’s a lot easier than I initially thought, especially when you don’t have a lot of routes yet. Syntax is similar though, so it’s super easy to learn. And I’m not sure if I’m just imagining this but I could swear my page loads easily 3 times faster! I think iron router was blocking/slowing down scripts like analytics, maps/places, webfonts, etc.

Only bummer is again the lack of package support such as ms-seo for example but I can live with that. Speed increase seems quite nice and I also think it fixes some load error bugs with Polymer. So far, I’m happy :smiley: !

2 Likes

I love Flow-router, Set params and query params are extremely easy.

I agree, iron router has fallen into a state of disrepair. I was using the waitOn and subscription callbacks, but these were being called inside a reactive computation that was pulling in other dependencies, causing rather expensive subscriptions to re-run (and loading spinners shown) even though nothing reactive had changed inside the callback itself.

It is going to be hard to switch given the amount of dependence on iron router, but I guess we gotta bite the bullet and go on.

2 Likes

I also made the switch from iron-router to flow-router and am very glad I did. Iron-router always seemed to require some extra struggle to understand, whereas with flow-router it just seems to make sense.

1 Like

Well it sounds like this thread has fully answered the question. Flow Router it is. I will be making the move and look forward to checking it out.

Although IR may be coming to its end, i would like to thank @cmather for all his work on it, i’ve enjoyed using it and its certainly been successful considering it came from the ‘early days’ of Meteor.

If there was a Meteor package hall of fame, it certainly belongs there. :slight_smile:

8 Likes

Yep, a heartfelt shoutout to @cmather (and @tmeasday as well as the other 60+ contributors) is in order for making our lives easier for all this time, providing one of arguably most wanted features to meteor as well as a concerted structure for our apps.

2 Likes

damn… now I’ll have to take another tangent to look into changing my router… :stuck_out_tongue:

1 Like