Question to MDG: Building routing into core

robertlowe · May 19, 2015, 4:07pm

I see what you did there.

lazmeister · May 20, 2015, 3:17pm

So Iron Router is out the door then? I was going to start projects with Meteor but this makes me step back and wonder if Meteor is serious in the JS Framework game

corvid · May 20, 2015, 3:22pm

Agreed, this is a web application framework, routes seem pretty essential. At least a very lightweight one should be a given.

iron:router seems mostly well done but there are a few things that irk me. Specifically, I hate how you can’t easily inherit controllers and implicitly pass data from the parent controllers to the children

Although it looks like flow-router supports this… is that true? I might switch over

aadams · May 20, 2015, 4:25pm

Hopefully MGD comes out with a router of their own.

But If you’re just starting a project, consider Flow Router instead of Iron Router. The consensus is Iron Router is no longer maintained.

I’m very hesitant to invest in something so fundamental as a router, so I probably won’t make the jump to Flow Router unless/until it gets official MDG support.

franky · May 22, 2015, 6:57am

I think the fact that less than 6 months ago Iron Router was the promising Router to be trusted and used, and is now abandoned supposedly, is the perfect reason for MDG to take over the Router situation. It makes no sense to trust it to community, when this could happen again. This is too important for MDG to leave to community.

satya · May 22, 2015, 7:33am

Not to mention IR has around 250+ open issues most of the time. I know they are not all bugs, but still for such a relatively small package.

rhyslbw · May 22, 2015, 10:04am

I agree on routing being handled by MDG, but as an optional add on and not installed by default. Flow is less complicated so should stand a better chance at being a robust solution

robfallows · July 9, 2015, 9:32am

Just to resurrect this as a reminder that MDG have announced that they will be bringing routing into core.

none · July 9, 2015, 11:48am

Which one? (-:
Or some new router?

maxhodges · August 6, 2015, 3:54am

Saturn V rockets were abandoned too, but they landed us on the moon. We’ve used iron router in every project to date and have gotten a lot of traction out of it. Maybe we’ll migrate them to Flow router some day, but presently we don’t feel any urgent compelling reason to do that.

We’ve built several small applications and one very large application with Meteor, so when I hear all these criticisms I feel like people are mostly making excuses when they could be building applications.

AndreasGalster · August 6, 2015, 6:17am

When packages break, that’s a reasonable excuse to me.

trusktr · August 7, 2015, 4:17am

@AndreasGalster Can you give an example of packages breaking?

thebionicman · August 7, 2015, 5:17am

For those who like Iron Router, why not form a group to take over maintenance (that is, if Chris didn’t object)?

arunoda · August 7, 2015, 6:12am

That’s a good point. I’d also like if someone willing to help FlowRouter too

Steve · August 7, 2015, 6:41am

Here is one: onRun hook is not fired EVER AGAIN when a hot code push happens · Issue #1219 · iron-meteor/iron-router · GitHub

ahref · August 8, 2015, 9:58am

If MDG do provide a core router I hope it’ll be optional.

Based on one of their current projects in splitting meteor-platform into smaller packages i’m sure it will be.

But eitherway it’ll give apps time/the choice to change over to the core router.

niallobrien · August 9, 2015, 9:38pm

Having to do auth at the template level with Flow Router is far from ideal for me. Iron Router works fine (use template subs) and is already on both server & client. Accounts-UI still has to be migrated I believe, there’s no oauth integration working just yet.
Though @arunoda has said that FR v3 will do serverside rendering, I just hope we won’t be forced to use React for it.

arunoda · August 10, 2015, 1:35am

Seems like you don’t get it properly. Whenever you stop doing router level subscriptions(we’ve good reasons for that), you can’t do template level authentication, other than checking for whether user loggedIn or not. That’s because we don’t have data in the router level. (Meteor.userId() does not need data).

This is the newest version of useraccounts core, which removes router level auth layer. Still you can flow-router specific stuff here. It uses loggedIn user checks in the router level. But it only check it with Meteor.userId().

UX in template level auth

Template level auth gives better UX to the user. You don’t need to render the content inside the loggedIn user. You can simply render the login form instead. This is a successful pattern used by many Meteor apps, including Telescope.

Router level is auth is proven?

In a typical PHP/Ruby kind of app, you can do auth level in the router level, because you have the data in the router layer. Client side apps are different. You don’t have the data in the router layer initially, you need to wait for that.

So, you need to show some loading screen whether you use IR, FR or anything else. So, even if you use router level auth, you need to interact with the layout layer to show the loading screen.

Even if you redirect the user, you need to show some message. Otherwise, user will get confused. Then you need to interact with the templating layer.

At the end of the day, you need to interact with the template level to do auth stuff, even you use it in the router layer. That’s why we recommend it to do it in the template level.

Decoupling Auth Logic from the Template with Router level auth

This is the one other argument for router level auth. Client side apps is all about templates and UI. You can’t decouple auth with it. With template level auth, we can implement the auth logic per componenet/template basic. That’s the same as we do it template level subs. So, we can build great reusable content with that. (That’s one way to do it, if needed)

We can also isolate auth logic into a once place and use some helpers like this:

{{#ifUserLoggedIn}}
  {{> editPostForm }}
{{/ifUserLoggedIn}}