Question to MDG: Building routing into core


#21

I see what you did there. :stuck_out_tongue_winking_eye:


#22

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


#23

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


#24

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.


#25

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.


#26

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.


#27

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


#28

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


#29

Which one? (-:
Or some new router?


#30

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.


#31

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


#32

@AndreasGalster Can you give an example of packages breaking?


#33

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


#34

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


#35

Here is one: https://github.com/iron-meteor/iron-router/issues/1219


#36

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.


#37

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.


#38

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}}

Read more here.


I don’t think Template level auth is far from ideal. It’s the ideal solution.

That being said, I don’t think everyone needs to follow it. We make it extremely hard to do Router level auth in FlowRouter. If you going with Router level auth, Flow Router is not the option.


#39

Adding server side routing to FlowRouter is very simple. But we didn’t do it for a purpose. Client side routing and Server side routing is two different thing for two different purpose. Apis are different in both case. Even if the APIs are the same, semantics will be different.

We also have a lot of great packages to do server side routing, just use them.

Read more about here.


#40

I didn’t get this. May be you were saying we need to use React for SSR at the end. right? :smile:

Yes, FlowRouter starts with React because SSR for React easy and it’s there. We use React for https://kadira.io and I wanted to do SSR for that. That’s why I start with React.

That does not mean, we won’t have it for Blaze. We already had SSR for Blaze. But the problem is, client side templates are not available in the server by default. We don’t had a simple way to make it correct without tearing down some core packages.

But with Meteor 1.2, this will be simple. So, we’ll have Blaze SSR too.

I’ll start it once I finish based SSR apis.

If someone wanna help me, try to make Blaze templates available on the server. Write a package for that. In 1.2 there are some Apis. See.