How can we build a better routing package?

[escamoteur]

Let's try if we come up together with an easier API for routing in mobile apps.

Some approaches that we should examine more closely are

• https://pub.dev/packages/routemaster

I always thought it's api way more approachable than that of go_router, so maybe it can be a starting point.

• https://pub.dev/packages/routefly

interesting approach, someone said it is similar to the of TanStack?

• https://pub.dev/packages/navigation_utils

@rydmike just recommend it

• https://github.com/sufftea/hyper_router

IMHO we should focus on mobile/desktop apps to give them an optimal developer experience.

I want to add, that I'm not an expert on this topic, but I believe that I have a pretty good understanding what makes a pragmatic API.

So lets collect what should the package contain, and what ideas do you all have.

One central decision will be will we have to use any kind of code generation or not. I always prefer solutions that will work without, but navigation isn't something that changes daily inside an app.

What would be helpful, is if there is somewhere an overview of the common navigational patterns inside today mobile apps.

We also have a discord: https://discord.gg/rk6TJkeJ

[medz]

Both are terrible!!! Absolutely terrible!!! We need something like react-router! Just use the RouterView Widget!

[escamoteur]

@medz I'm happy to have you here but it would be great if you could lay out why they are terrible, and be more constructive

[pythonhubdev]

ReactRouter has different modes of routing as well and I guess you are referring to the <BrowserRouter></BrowserRouter> Component from ReactRouter @medz. Why do you think Tanstack router is terrible I have been using it and recently switched to Tanstack Start as well looks absolutely easy to use and zero-configuration at all.

[lukepighetti]

one option i haven't seen is going all in on file based routing

• https://tanstack.com/router/v1/docs/framework/react/routing/file-based-routing
• https://nextjs.org/docs/app
• https://docs.expo.dev/develop/app-navigation/
• and a unique version of this in the dart world https://dart-frog.dev/basics/routes/

[escamoteur]

@lukepighetti that's what https://pub.dev/packages/routefly does

What exactly do you see as the big advantage? What a limitations of this approach?

[lukepighetti]

ime advantages

• intuitive structure that matches actual string paths
• gives a nice place to put code related to routes
• which also keeps library code folders cleaner with less single-use components
• routing scheme unlikely to change which keeps web urls predictable over time

disadvantages

• changing routing scheme can cause big merge conflicts since you're moving big chunks of the codebase
• hard to tell which page you are viewing in IDE tabs because it usually is named page.dart instead of something like home_page.dart. routefly tries to address this but they lose one of the nice features of having a dedicated folder for each page

[escamoteur]

but clearly requires code generation.

[medz]

@medz I'm happy to have you here but it would be great if you could lay out why they are terrible, and be more constructive

@escamoteur They all essentially haven't escaped Flutter's terrible routing. It's entirely possible to manipulate only history and completely avoid Flutter's routing. The worst thing about Flutter routing is its simplistic stack pattern. That is, if the shell class never gets its state properly preserved, it can't update routes by simply rebuilding the child. I previously submitted a bug report related to Go Router in Flutter, and they claimed to have fixed it, but in my actual testing, it wasn't. So I don't use Go Router at all now. Routemaster and Routefly have similar issues. This is caused by Flutter's routing mechanism. It should build a better implementation internally, like react-router.

ReactRouter has different modes of routing as well and I guess you are referring to the <BrowserRouter></BrowserRouter> Component from ReactRouter @medz. Why do you think Tanstack router is terrible I have been using it and recently switched to Tanstack Start as well looks absolutely easy to use and zero-configuration at all.

@pythonhubdev Not entirely correct, but mostly correct. I mean, you should use something like <RoiuterView>. Update the path differences through methods within the route.

Does Tanstack have this package? The problem with routemaster is that it offers no advantage over go_router.

The only redeeming feature of routefly is its "Filesystem Routes" functionality, but internally it still uses Flutter Router functionality.

Therefore, essentially all routing packages that use Flutter's built-in routing are terrible. They're just using a different form; there's nothing to brag about.

These people don't even understand that routing is more than just full path navigation! These people really should look into how svente, vue-router, and react-router implement shell functionality (in frontends, it's usually not called a shell, but rather a parent view or routes layout).

---

/: - Layout
  - / - home
  - /settings  - Setting

This example easily demonstrates the weakness of all current routes: they have correctly implemented shell routes, but layout rebuilding is unavoidable.

When my path changes from / to /settings, the layout should never change.

[escamoteur]

@medz now you have my full attention, you know that I am open to unconventional (for Flutter ) ideas.
So you say it could be a good idea to completely ignore the flutter routing and build something new?
wouldn't that constantly work against the framework? Any example how you are currently doing routing?

Not sure that I follow what you mean when I navigate from / to /settings that the layout shouldn't change

what are your thoughts on https://pub.dev/packages/navigation_utils

[medz]

@medz now you have my full attention, you know that I am open to unconventional (for Flutter ) ideas. So you say it could be a good idea to completely ignore the flutter routing and build something new? wouldn't that constantly work against the framework? Any example how you are currently doing routing?

what are your thoughts on https://pub.dev/packages/navigation_utils

Yes, it's very helpful.

For example, in my diagram, when I switch from /demo/1 to /demo/2, DemoLayout should not rebuild at all. It will be correctly preserved, and only child routes will be pushed in the children's RouterView.

Most programs don't require centralized routes definitions (the only benefit being better management for larger projects), but you can refer to vue-router, which defines routes but still achieves similar capabilities.

---

This is a completely declarative example that conforms to Flutter's Widget design philosophy and complements explicit design features such as watch_it/get_it.

[medz]

Such routing not only runs correctly in native code, but also aligns with the web building paradigm in Flutter's web implementation. The reason I criticize go_router and similar tools is simply because web scenarios require extensive layout work, and paths must be user-friendly, readable, and easily shareable. For example, the / route should be associated with home! We shouldn't have /home! It's incredibly annoying.

[escamoteur]

@medz that actually looks indeed how I would expect routing to be defined, not as separate mechamism but like a TabBarView.
the nested Routers would register with the parent ones so that deepLinking could be easily implemented?
How to you navigate from one nested route in one router to a complete different one?

Oh, now I see, even nested routers can define the same paths an would update if the current path is changed?

[medz]

Not sure that I follow what you mean when I navigate from / to /settings that the layout shouldn't change

As shown in the image above, the Home element has a bottom NavigationBar. When the routes within this layout change, it shouldn't need to be rebuilt.

However, currently all packages require it to be keep-alive, which is completely unreasonable. When I route from / to favorites, the HomeScreen shouldn't be rebuilt! This is a reasonable confirmation of minimizing the update scope. And routing itself can easily and correctly implement this, which is exactly how it should be.

But currently, all routing packages either don't implement this, or require it to be keep-alive, which is utterly absurd.

[medz]

even nested routers can define the same paths an would update if the current path is changed?

Yes, Just like in the web, when the same path is defined, it represents both the parent path itself and the final route. Route content replacement should be checked from the deepest level, and the outermost layout should not be changed.

[escamoteur]

@medz how can you directly add a RouterView to a TabBarView? Still have a bit problem to imagine how you actually navigate in such a system.
also compared to systems like route_master your route definitions are distributed over a lot of Widgets, that might make it difficult to keep the overview