Great find. I use Veliov Meteor Mailer and I’ve contributed to it (awesome package btw). I find their devs replying very fast and to be very helpful. Last commit to Flow Router Extra was 10 hours ago, so that looks very good.
We started off with Iron Router, but ran into counter-intuitive weirdness and so dropped it. We looked at the then-nascent Flow Router, but found its API a little clunky and Arunoda’s comments about future direction at odds with our goals.
Given a bias for Express’ elegance and a belief that, yes, a router should only route — we baked PageJS into a package (along with Express for a server-side REST API). We’ve tweaked PageJS to make it more Express-like, particularly with regard to error-handling, and I expect we’ll further that over time.
Thus, I’d recommend PageJS as an easily digested library that gets you vanilla routing client-side. I’m happy to post our router package if someone’s interested in using it.
I’ve seen flow-router-extra is already mentioned here.
Thanks for everyone who already using it.
And everyone who is looking for up to date FlowRouter is welcome to try flow-router-extra. We keep all dependencies up to date, test it with every Meteor release, and publish updates when necessary.
Although it’s a fork of original FR, it’s extended with:
- Latest features - ES6 Import support, latest
qs
andpage
NPM dependencies - Missed hooks -
waitOn
,data
,onNoData
andwhileWaiting
- Ability to preload Images, Fonts and other resources
- No need to use
BlazeLayout
, efficientrender
with support ofyield
,layouts
and with respect torequestAnimationFrame
is build-in
Thanks to @theara for pointing me to this thread
It sounds good.
@dr.dimitru Thanks for join us in this thread with your awesome Flow-Router fork
Have you considered reaching out to @arunoda for maintenance rights in the original repo? This would avoid much of the mess associated with a transition like this (i.e migrating issues, broken links, promoting new namespace, etc.)
@ramijarrar I don’t think @arunoda seeking for merge. As he is not share my vision on some features - see this Twitter post
Anyways, @arunoda - if I’m wrong, I’m ready to merge and put my hands on original FR as maintainer
Dimitriy, how do you address Arunoda’s points about waitOn essentially turning FR into IR?
I personally think waitOn
was one of the most confusing (and UX harming) parts of IR, so putting it back is kind of going back on one of the main reasons to use FR. I think FR got one huge thing right: The router should act as just another source of data, rather than doing things like data loading etc.
imho, do not use it if you don’t need it.
Or it’s uncomfortable to know want such functionality is implemented?
When you recommend a library, you are also recommending that library’s documentation - the documentation for flow-router-extra
focuses heavily on those new hooks, which pretty significantly change how the router would be used. Anyway, if I were Arunoda I would want my project to be taken over by someone who had contributed heavily in the past and shared my vision for the future. I think that’s the difference between a fork and a maintainer handoff.
Guys,
First of all, I am sorry again for you guys to see a post like this.
Things happens, so we had to move on.
Here’s my idea about the future of FlowRouter.
Future of FlowRouter
@diaconutheodor volunteered to maintain the FlowRouter and he made a fork. (That’s something I suggested).
But it seems like there are some others wanna help this project to get maintained.
So, now I think it’s better to select GitHub organization where I can transfer the repo for new development. I hope @diaconutheodor could work on this and team up with the people who could help on this process.
I won’t be shutting down the current FlowRouter guide which is on our kadira.io domain. But I think it’s better to host is somewhere else, may be the Meteor Guide.
(May be we already have similar content in the Meteor guide)
Ideas to Manage FlowRouter
My plan for FlowRouter for v4.0 was a fully managed SSR. But that’s pretty hard and I could make it work 80%. But getting the next 20% is pretty hard.
So, my suggestion is just forget about SSR for a short term. Get all other fixes in the FlowRouter SSR branch and make a release.
As @sashko mentioned, one thing FlowRouter did right is try to decouple routing from the app logic. So, I wish it’ll be the same.
I am now maintaining FastRender and InjectData. I’d love to help maintain FlowRouter as well since they are closely related.
I also have a fork of FlowRouter available as staringatlights:flow-router
If you depend on FastRender I’d recommend you use my fork until your FlowRouter-fork-of-choice updates their dependencies to use staringatlights:fast-render
instead of meteorhacks:fast-render
.
Edit: Since upgrading FlowRouter directly can cause a huge pain in updating dependencies. A quicker way to get your app up and running on Meteor 1.4.2+ is to continue to use meteorhacks:flow-router
and/or meteorhacks:fast-render
and simply add staringatlights:inject-data
to your project. This will monkey patch the functionality so that it works for Meteor 1.4.2.
Is there a router out there that allows me to use Blaze and Vue.js side by side? I’m not sure what the issue is, but I got the impression from @akryum that FlowRouter does not play well with Vue.js.
I have been using flowrouter-ssr and ssr has stopped working on 1.4. Is there something I can do, to get it to work again?
I have placed a post on Flow Router expressing my interest to manage it 4 days back and I am still waiting to hear from Arunoda - https://github.com/kadirahq/flow-router/issues/708
As I said in PM, FlowRouter doesn’t play well with Vue out-of-the-box, but it’s still possible to make the two work together. I didn’t try to use Blaze and Vue side-by-side, but you could change how the route are handle depending on if it is a route pointing to a blaze page or to a Vue component.
Will you explain the differences in how the route is handled, Vue vs. Blaze?
Thanks @akryum,
If you mean nested routes in this sense
Then, my application does not use nested routes.
Everything in my application uses this format:
I don’t use parameters on the route, I use Session or Mongo to pass state between routes.
I see that repo was last updated almost a year ago, if you had to start fresh today, in my situation, would you approach it the same?
Add staringatlights:inject-data to your project. If it doesn’t work for
some reason, open an issue at github.com/abecks/meteor-inject-data