Question to MDG: Building routing into core


#1

Do you guys intend on building routing into core?
It feels like Iron Router is no longer being maintained, with 240 open issues on Github and latest update half a year ago…
It’d be sensible to have this vital functionality natively built-in and maintained by MDG.


Should I be using Iron Router (or is it dying)?
Routing: IronRouter is recommended, and can I split the html?
MDG needs to be more involved with the community
#2

+1, I think that it’s good if Meteor build routing into core like Laravel PHP Framework style.


#3

Have you tried Flow Router? It seems to be fairly well maintained by @arunoda, an important member of the Meteor community.


#4

I second this post :smiley:


#5

It seems IR is coming to an end. This issue has a fix that is waiting to be merged for 2 months…


#6

I understand you have your hands full with up and running Galaxy. But when it’s done you sd really give it a thought. Because community projects come and go, but this is too vital IMO.


#7

Since Chris seems to be done with the project (and it has a load of bugs), I’ve found myself slowly pulling everything I can out of Iron Router: onwait subscriptions, events, helpers, etc.

I’m trying to move to template level subscriptions.

The community needs a maintained router, and IMO this should be a core feature of Meteor.


#8

Yeah, I think Flow Router is the best option right now, and if anything gets integrated, it should be something like Flow Router, decoupled from the views of your app (contrasting with Iron Router), making it easy to use with any view layer.


#9

I asked Ekate, the package manager at MDG about this on Meteor Day. Basically they can’t say that they will never build their our router, but at this point the community solutions are doing a good job so it’s not a priority to build a core router feature-set.

You can always add it to the Meteor roadmap and allow people to vote on it, but I don’t feel it’s really a priority either. I’m not finding routing to be a really bottleneck in creating Meteor web applications.

Cheers!


#10

Yes. That’s why we started Flow Router in the first place. But it was a in-house project and never wanted to be the default router :slight_smile:

But, seems like I need take special care on Flow Router. So, I’ll work on next week ironing out some of bugs. I’ll also set some long term goal of the router and the core idea behind it. Then we can build a team to manage the router. Even if I busy, flow router should get fixes.

After Flow Router became stable (it’s not unstable now either) we can think of looking to push it with default meteor release. With that, community can manage the router and I think that’s something good.


#11

Completely agree.

If I knew then what I know now, I would never have integrated it so deeply in my views. I just want something simple and light with intuitive syntax – that’s available client side AND server side – and bug free for the most part.

Too much to ask?


#12

There’s also the server-side version of flow-router: meteorhacks:picker


#13

I have used Flow Router in two smaller apps I am working on and I really like it, I have found a few small issues (will get a chance to do an issue soon), I really like the approach it takes and the reduced re-rendering (an issue I am well aware of now in a more complex app).

I am also moving to template level subscriptions and really find that simpler to reason about in terms of where my front end data is and how to build components around that data.

However - I see the need for an MDG ‘backed’ or ‘approved’ router for the sake of all the other packages that depend on a router, I know it will take a while for them to update to whatever the community starts using if there is not an ‘official’ solution.

In saying that, maybe some other best practice will start to emerge that decouples routing to enable different routers? Not sure how that would work but would be interesting.


#14

I have also used this package while working with the Square API (to provide responses to webhooks calls), a basic use case but no issues so far.


#15

This topic is popping up here and there…

As far as I understand MDG is panning to introduce “approved” community packages with some spacial badge in Atmosphere and listed in some separate list. I think that would solve a lot of similar questions like this. @sashko, do you have any plans when you will do that?


#16

Are you an employee of MDG now?


#17

No.
[need some chars to complete.]


#18

you said “we can look at pushing it with default meteor release” can you explain? means you’ve discussed with MDG and they are onboard with the idea? I don’t see it on the roadmap.


#19

I mean, I hope to happen that.
Anyway, I’ve heard about ideas on getting community packages to core.


#20

OK thanks for clearing that up.

Cheers!