It seems a good way (or simple way) at first but I really like the current approach of flow router.
I’m not a next.js expert and there might be solutions for all the things that flow router can do but I believe a router should be defined to call a page.
I like the Next approach. It allows the framework to take complete control on code splitting pages and pre-generation. Nuxt for Vue has a similar approach. The problem however is that both rely heavily on their router. Nuxt relies on vue-router and next on ita own router. For next all the hooks and functionality was customly built. If I understand correctly there were reasons that they did not use React Router.
Having said that, we could maybe provide a way to generate a route configuration based on a file structure in a pages folder. This would allow the opportunity for free code splits and UI frameworks could integrate its results into their router of choice
NextJS is really cool, but I find it better (subjective opinion) as a framework for websites. The file-path router that it ships with has limitations especially when it comes to conditional routing etc. Many times when I have used it in the past, I wind up having to create my own ExpressJS router to satisfy things it can not do. If you are using Blaze…I would suggest sticking with FlowRouter as it is far more robust, though I will admit that the NextJS router is pretty darn cool for what it does!
Next now handles dynamic routing and intl routes but this one-file-one-route approach gives them a hard time to handle translated routes (which is important for SEO). No doubt that they will come up with a solution sooner or later, but it would be easier with other approaches.
We’re using Next.js extensively where I work, and while I like certain aspects of its router vs. React Router, it’s not all roses. There are thorns too.
One nice thing about Meteor is you can mostly pick and choose your router.
I would echo what @captainn is saying, I’d rather pick and choose and Meteor hits that sweet spot between sensible defaults and flexibility. For static sites, we use CRA hooked up Meteor backend when data is needed.
Having said that, we could maybe provide a way to generate a route configuration based on a file structure in a pages folder. This would allow the opportunity for free code splits and UI frameworks could integrate its results into their router of choice
I would favor this approach. For users just starting out, and to get something up and running quickly, a file-based router makes sense. But you quickly run into a need for dynamic routing. At which point, the file-based approach becomes a hindrance (you end up organizing your code based on the URL structure, rather than what makes sense code-wise). A 3rd party script that takes your file structure and spits out a config file for flow-router or react-router might be a good way to let new users ease into meteor routing, while not reducing the power of dynamic routings.
My app is so old, I’m still using IronRouter. I realize I need to probably switch to flowrouter at some point, but it works, and there’s a lot of dynamic stuff I’ve coded in that I don’t want to rewrite if it ain’t broke