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:
with preserving state of each page
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:
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.
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:
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.
/shop/catalog/
./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.
I think long-term it will have to be more closer to how GoRouter, Beamer and other works. Something similar to:
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.