Support bottom navigation bar navigation

[itsJoKr]

Hey, I really like where this package is going, and this solves my biggest pain point when working with other routers. I would like to give few of my opinions here, you can dismiss them, but they might be helpful.

---

When talking about bottom navigation bar navigation we identify two cases:

1. with preserving state of each page
2. without preserving state of each page

The 1) is more often found in iOS, the 2) is more often found in Android, but there is no rule and user decides in the end what they want.

You've implemented 1) in example with use of an additional query parameter which then persists in navigation.

• I think it's not the most convenient way to do it, query parameters usually have some other meaning. Like when you are filtering. The expected way would be using the path parameters like /shop/catalog/.
• I'm not sure about keeping whole state in the URL. This results in very long and unpractical URLs like /shop/.catalog-tab/..catalog/..category~id=home-decoration/.basket-tab/..basket/..checkout for a simple bottom navigation screen. I would keep the state somewhere in octopus (not sure how GoRouter does that). This means that you cannot copy-paste URL or deeplink that will open exactly two specific pages inside the bottom navigation. But I don't think anyone would ever need that.

For 2) I also think it's more natural to have path parameters.

To sum up

If you want to implement something like what I've proposed or potentially many other changes, I think limitation currently is that you return widget based on the route, so you have no additional control of it.

        Routes.signin => const SignInScreen(),

I think long-term it will have to be more closer to how GoRouter, Beamer and other works. Something similar to:

    Routes.signin => OctopusRoute(
        SignInScreen()
    ),
    Routes.statelessHome => StatlessShellRoute(
        StatelessHomeScreen()
    ),
    Routes.statefulHome => StatefulShellRoute(
        StatefulHomeScreen(),
        potentiallyOtherFields: true,
    ),
  };

I know that would make this look more like GoRouter, Beamer (and others), but they have a good reason why they went this way. You need something like that to cover all the cases. But none of them (as far as I know) can solve infinite-routing, and the repeating screens in different URL locations.

[daddowzoubair]

+1

[PlugFox]

This results in very long and unpractical URLs like /shop/.catalog-tab/..catalog/..category~id=home-decoration/.basket-tab/..basket/..checkout

This is the only way to reflect state changes depending on the URL. If we are talking about real routing and not just a hardcoded template engine like go_router.

Storing something in a global variable or singleton or some hidden state is also a crutch and not an option at all.

more like GoRouter, Beamer (and others)

Don't expect this library to follow their example. These are the worst routers possible ever and the reason why this library exists.

The main emphasis here is on the absence of template engines, honest state, and the absence of global keys and hardcode.

If you don't like the way the URL behaves, then everything is very simple, make your own small RouteInformationProvider class instead of the existing one, it's 15 minutes of work.

Or don't use nested nodes.