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

Wow, I turn my back on Meteor for a few months and suddenly Iron router is old…well crap : - )

I would first wait to see what @cmather has to say and @tmeasday which is now working for Meteor. I’m planning on waiting at least until the next meteor update I have a feeling that routing will now be part of core and iron-router might be the routing package.

Also flow router is being maintained now but @arunoda has a number of packages and some are barely maintained like meteor MUP so I don’t think it’s any different long term then iron-rotuer.

My suspicion is that flow-router is more likely to be part of core than iron-router – taking a hint from the comment above from @sashko who is part of the Meteor team.

You also express the same comment on somewhere on the FB as well. Let me answer here. :slight_smile:

At Kadira we always maintain our projects. Some projects are hacks and some are not hacks. We maintain a lot them very actively and property including FastRender, subsManager and etc.

Mup and cluster are two different projects which depend on the infrastructure and how you set up it. For an example, we asked users to use a clean Ubuntu instance and users use Ubuntu with node 0.12.x installed on it. So read the manual first. Anyway We launched mupx to solve this issue. We are releasing a new stable version soon. In mup a lot of questions are support questions. We don’t have resources to handle them. I think the community their doing a good job. That’s why you see a lot of open issues.

About IR

I never blame or comment @cmather or Tom when we talk about FlowRouter. We found a new way to routing and it’s simple and easy to manage. Now it’s stable and now we are experimenting new things like SSR and load time improvement.

IronRouter fail is a good example of how small our community is and how we care about packages. If IR is doing not well, fork and fix it. Then may be publish under new name. Later on we can merge it to IR back. That’s what OpenSource is.

Instead of forking IR, we build a one from scratch.

5 Likes

Personally I think it creates fragmentation on something that is core. This is what I hope meteor adds this to core. When looking at Ruby on Rails having routing and the way you structure your app set is a big deal and I believe the same approach needs to be in Meteor.

I’m a big fan of most of your packages and they’re all amazing and I love kadira.

I still don’t understand why not fork iron router you talk about this yourself but created a new package creates fragmentation. My advice to wait until we see how meteor will handle this.

Bye the way I read the manual and always run a clean install so I really hope MUP gets an update I do believe there are some issues.

2 Likes

How do I rewrite helpers that relied on this.data? I’m struggling with this bit.

If you used to use Iron Router evil data() function and to pass a crowded reactive context all the way down to each subtemplate, you can emulate the same evil behavior by using a big #with around the main templates of your routes. However, I recommend changing this and getting the data closer to where it is needed. We can discuss your real case if you want.

Thank you for your reply. The data is rendered in a template called
dataView and I am trying to use it in a Template.dataView.helper… I used
to do this.title for example… If I want to return a value based on a
param within the same template how should I do it?

But what is title? Where does it come from? (what is the query that loads it?)

Another helper, which maybe is the issue as this is not how it was done with iron:router. This is the helper, the view is rendering {{record.title}}, can I then use that record object in the helper?

Template.dataView.helpers({
  record: function() {
    var dataId = FlowRouter.getParam('dataId');
    var record = Datas.findOne({ $or: [{slug: dataId }, {_id: dataId} ] });
    return record;
  },
  byWho: function(){
  	var data = Template.currentData();
    console.log(this.record);
    var user = Meteor.users.findOne(Template.currentData().updatedBy);
    return user.username;
  },
  timeAgo: function(){
    return moment(this.updatedAt).fromNow();
  }
});

Maybe you can use this:

Template.dataView.helpers({
  getData: function() {
    var dataId = FlowRouter.getParam('dataId');
    var record = Datas.findOne(
      { $or: [{slug: dataId }, {_id: dataId} ] },
      { fields: { updatedBy: 1, updatedAt: 1 } }
    );
    var user = Meteor.users.findOne(
      record.updatedBy, 
      { fields: { username: 1 } }
    );
    var timeAgo = moment(record.updatedAt).fromNow();
    return { username: user.username, timeAgo: timeAgo) ;
  },
});
<template name="dataView">
  {{#with data=getData}}
    <div>data.username</div>
    <div>data.timeAgo</div>
  {{/with}}
</template>

@arunoda - what is the official view on this? What in your view would be best practice using flow-router when rewriting helpers?

OK, I have worked out where my brain fell over. I needed

{{#with data}}

As per the docs…

https://kadira.io/academy/meteor-routing-guide/content/subscriptions-and-data-management/with-blaze

Thanks all the same.

I think using getParam() inside the helpers in the common way to do it.

I wish the Discover Meteor book would be updated to use Flow Router then - I’m a newcomer, and this issue is slowing me down a bit. It looks like the best thing to do is just keep going through the book, but not worry too much about understanding every little detail of I.R.

2 Likes

I would switch to Flow Router. I’m about to do the switch. I did a test conversion the other day and it took me (at most) 3-4 hours. It’s fairly API compatible with Iron Router.

1 Like

I’m new to Meteor. I started off with Iron:router, it worked ok. I noticed people were saying iron:router was dead so thought I’d better stay current and looked at flowRouter.

I love how much simpler it is and totally get putting subscriptions in the template context. BUT! I still feel like its missing an onWait method where you would wait for your MAIN subscription first like some main body text THEN once thats loaded you can depend on template subscriptions for the rest of the templates like sidebars, comments etc. To me this would feel more natural.

Currently every route change produces a kind of flicker effect where data goes missing for a few milliseconds shows a “loading sign” and pops back again with new data. It feels odd especially if you have a massive footer that pops in and out of view for a few milliseconds when data is loading.

1 Like

MDG Router… ROTFLMAO

2 Likes

Did you tried the FastRender package? Also you can cache subscriptions with the subs-manager package.

I thought the fastRender package was only useful for when a user first enters the website and the subs-manager would only be effective if the user was going back and forward through their browsers history. I’d love to be wrong though :grinning:

I guess what I’m really looking for is a nice solution for smooth page transitioning with flowRouter.