Multi stack routes

[lulupointu]

This conversation aims at describing a new API called "multi-stack routes" and the changes needed internally in GoRouter (in particular the path matching algorithm).

This document is the result of internal discussion and might therefore seem esoteric but is mainly a way to discuss this matter with @csells is an environment with nice code highlighting 😄

External usage

The current usage of this API would look like this (names are likely to change):

GoTabbedRoute(
  path: '/',
  controller: tabbedRouteController,
  tabRoutes: [
    GoRoute(
      path: 'books',
      pageBuilder: BooksPageBuilder(),
      routes: [
        GoRoute(path: ':bookId', pageBuilder: BookPageBuilder()),
      ],
    ),
    GoRoute(path: 'settings', pageBuilder: SettingsPageBuilder()),
  ],
  builder: (context, state, child) => Scaffold(
    body: child,
    bottomNavigationBar: BottomNavigation(
      currentTabIndex: tabbedRouteController.currentIndex,
      onSelectTabIndex: _selectTabIndex,
    ),
  ),
)

Navigating to different tabs can be done with context.go as usual:

context.go('/books');
context.go('/books/1');
context.go('/settings');

The addition of this API (compared to simple route wrapping via builder) is that:

1. tabbedRouteController which allows to switch between tabs using tabbedRouteController.go(index).
2. tabbedRouteController keeps track of the current index, accessible using tabbedRouteController.currentIndex
3. The tabs are lazy loading but their state is kept once inserting in the widget tree. When you use tabbedRouteController.go(index) to go back to a previous tab, you will find it where you left it.

It should be noted that this is an expansion of the current GoRouter API, since it is simply impossible to achieve this behavior with the current GoRouter API (even with extensive url tracking or other tricks). This is because GoTabbedRoute introduces (hidden) nested navigator which each have their own stack, hence the name: multi-stack API.

Internal changes

Due to the way GoRouter is written, some internal changes are necessary. The most important one being the path matching algorithm. This will NOT be a breaking change for the existing GoRoute, and is only an internal technicality.

To appreciate the challenges of the following topics, try to reflect on the fact that a GoTabbedRoute can be inside a GoTabbedRoute inside a GoTabbedRoute etc. Introducing algorithm general enough to handle this recursivity is the real challenge.

1. Translate matching GoRoutes to Pages

The first change comes to the way a GoRoute is translated to a Page. Previously, each GoRoute which where matched by the path matching algorithm formed a this, which could be translated to a list of Pages (via GoRoute.pageBuilder). This list of Pages would then be used in Flutter Navigator.

However, as described earlier, GoTabbedRoute to create internal Navigators. Therefore, even one of its tabRoutes is matching, its corresponding page should not be used in the main Navigator. Their should be a way when building the page to give the internal routes to its associated GoRoute (see description in "Path matching algorithm").

2. Path matching algorithm

First, agreed convention on path matching on GoTabbedRoutes is the following:

1. If only GoTabbedRoute is match, but none of its tabRoutes, this is not a match
2. tabRoutes are matched like regular sub-routes, by appending their path to the path of the parent GoTabbedRoute
3. routes (which are routes displayed above GoTabbedRoute.builder) are matching by appending their path to any of the tabRoutes path.

Here is an example for clarity

GoTabbedRoute(
  path: '/root',
  tabRoutes: [
    GoRoute(
      path: 'books',
      pageBuilder: BooksPageBuilder(),
      routes: [
        GoRoute(path: ':bookId', pageBuilder: BookPageBuilder()),
      ],
    ),
    GoRoute(path: 'settings', pageBuilder: SettingsPageBuilder()),
  ],
  routes: [
    GoRoute(path: 'other', pageBuilder: OtherPageBuilder()),
  ],
)

Valid routes are:

'/root/books' // Rule 2
'/root/books/0' // Rule 2
'/root/settings' // Rule 2
'/root/books/other' // Rule 2 & 3
'/root/books/0/other' // Rule 2 & 3
'/root/settings/other' // Rule 2 & 3

Rule 1 stating that /root is not a valid route.

Challenge 1: Rule 1
The first rule, boiling down to the fact that a GoRoute can have a matching path but is not matching (depending on its subroutes), is currently impossible.

Challenge 2: Rule 2 & 3
The second and third rule describe the fact that a GoRoute can have two kinds of subroutes: internal routes (tabRoutes in our case) and external routes (routes).

internal routes should be matched first by appending their path to the parent path:

• If childRestLoc is empty, they can return the list of matches immediately
• If childRestLoc, they should use it both in their subroutes and it should be used for the external routes

external routes:

• If there are no internal routes: external route should append their path to the parent path (as regular GoRoute do)
• If there are internal routes: external route should be matched after internal routes, and should append their path to the path of any internal route with a valid subLoc (name taken from GoRouterDelegate._getLocRouteMatchStacks)

In both external routes cases, if they have no subroute and childRestLoc is not empty, this route should not be considered as matching.

1 (Translate matching GoRoutes to Pages) and 2 (Path matching algorithm) compatibility

Something to keep in mind is that point 1 and 2 are intrinsically linked because 2 is used to return a bunch of GoRoutes, which should then be turned into Pages using 1.

Limitations:

This API does not allow someone to push into a specific tab. This might be possible by adding TabbedController.push but has not been explored yet so idk if this causes any implementation issue.

[esDotDev]

This is really interesting. You're tackling the one thing that has always stymied me with the nested Router approach with GoRouter, which is how do you have pages outside the tabs, these 'external' pages as you call them.

I'm not totally clear what /root/books/0/other' would map to, would it map to something like:

[
   BooksPage() // in tab bar
   BookPage() // in tab bar
   OtherPage() // fullscreen
]

?

[lulupointu]

/root/books/0/other would map to the following page stack:
[Scaffold([BooksPageBuilder, BookPageBuilder]), OtherPageBuilder] (can you understand the notation ? [] represent a stack and () represent nesting)

[lulupointu]

From your edit I think you understood. Let it be clear that BookPage is stacked on top of BooksPage, both of them being in the first tab.

[esDotDev]

Ya, very nice, looking forward to playing with this, this ends up acting quite similar to gmail, where a dangling ?compose can be added to any URL to bring up the compose modal.

[leoshusar]

Here is my idea.
My use case would be for server side generated tabs. The "parent" GoRoute, whose descendant would contain tabs (or Drawer with PageView), would have an optional flag, something like newScope or hasOwnScope or something.

The code would look like this:

[
  GoRoute(
    path: '/users/:userId',
    newScope: true,
    pageBuilder: (state, context) => MaterialPage<void>(child: UserPage(...)),
    routes: [
      GoRoute(
        path: 'albums/:albumName',
        pageBuilder: (state, context) => MaterialPage<void>(
          key: state.pageKey,
          child: AlbumsPage(tab: state.params['albumName']!),
        ),
        routes: [
          GoRoute(
            path: ':albumId',
            pageBuilder: ...,
          ),
        ],
      ),
    ],
  ),
]

and possible routes would be:

/users/1/albums/winter
/users/1/albums/summer
/users/1/albums/whatever-the-server-returned

That flag would do this:

• if you call context.push('/users/1/albums/winter/1') on /users/1/albums/winter page, it would add another page to stack as usual, this would open the selected album.
  Then the back button would take you back to the /users/1/albums/winter.
• if you call context.go('/users/1/albums/summer'), it would keep the stack until the last newScope: true route and replace only what is after it.
  So in this case it would keep /users/1 and replace albums/winter with albums/summer.
  The back button would then take you to /users/1.

Does this make any sense?

IMO the router class should only have definitions of routes and where those take you, not any business logic, so:

• I would be able load available tabs in the AlbumsBloc, not in the router class
• I don't like the idea of defining UI inside the router class. With the GoTabbedRoute, you would need to define any Scaffold, AppBar, TabBar... styles in your router class if I guess correctly? I think it's much cleaner to put these things in the AlbumsPage

But on the other hand with the GoTabbedRoute it would be easier to assign paths to static tabs, when you don't generate them dynamically, since you would be able to use them with the GoRoute...

Hmm, this is hard.

EDIT: as I am thinking of it, instead of optional boolean newScope could also be GoScopedRoute.

[lulupointu]

I'm sorry but I'm not sure of what you are trying to do here.

If you want a page inside another (according to the definition I give) you must be passing a child argument that the parent can use to place the child where it wants. In your case, how do you say where you want to place the child in UserPage ?

Maybe you did not understand what we are trying to achieve here (in which case this is my fault). You can have a look here if you want to visualize what we are trying to do. You can also read the associated discussion if needed.

I don't like the idea of defining UI inside the router class. With the GoTabbedRoute, you would need to define any Scaffold, AppBar, TabBar... styles in your router class if I guess correctly? I think it's much cleaner to put these things in the AlbumsPage

Not at all. I defined styles along side routes for easier visualization but ultimately you should create a widget which creates the outer UI.

Click to reveal a correction of the example I provided

// BAD
GoTabbedRoute(
  path: '/',
  controller: tabbedRouteController,
  tabRoutes: [
    GoRoute(
      path: 'books',
      pageBuilder: BooksPageBuilder(),
      routes: [
        GoRoute(path: ':bookId', pageBuilder: BookPageBuilder()),
      ],
    ),
    GoRoute(path: 'settings', pageBuilder: SettingsPageBuilder()),
  ],
  builder: (context, state, child) => Scaffold(
    body: child,
    bottomNavigationBar: BottomNavigation(
      currentTabIndex: tabbedRouteController.currentIndex,
      onSelectTabIndex: _selectTabIndex,
    ),
  ),
)


// GOOD
GoTabbedRoute(
  path: '/',
  controller: tabbedRouteController,
  tabRoutes: [
    GoRoute(
      path: 'books',
      pageBuilder: BooksPageBuilder(),
      routes: [
        GoRoute(path: ':bookId', pageBuilder: BookPageBuilder()),
      ],
    ),
    GoRoute(path: 'settings', pageBuilder: SettingsPageBuilder()),
  ],
  builder: (context, state, child) => MyScaffold(
    currentIndex: state.currentIndex,
    selectTabIndex: state.selectTabIndex,
    child: child,
  ),
)

class MyScaffold extends StatelessWidget {
  final Widget child;
  final int currentIndex;
  final void Function(int) selectTabIndex;

  const MyScaffold({
    Key? key,
    required this.currentIndex,
    required this.selectTabIndex,
    required this.child,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: child,
      bottomNavigationBar: BottomNavigation(
        currentTabIndex: currentIndex,
        onSelectTabIndex: selectTabIndex,
      ),
    );
  }
}

[leoshusar]

Thanks for an explanation. My comment is based on this question, maybe it's not exactly the same - but similar?
Anyway I will try to explain my idea more, maybe it will still fit here.

There I was only talking about static predefined tabs (user info, role info...) but in this discussion I have extended it to remote tabs.

In my case the parent would not receive the child but only index or name of the selected tab. My currently implemented code looks like this:

Example code

// removed non important parts
@override
Widget build(BuildContext context) {
  return StreamBuilder<User>(
    stream: _userBloc.user,
    builder: (context, snapshot) {
      return TabNamedPagerBuilder(
        controller: _tabNamedController,
        pages: [
        if (!snapshot.data!.isServiceAccount)
            const UserRolesPage(),
          const UserResourcesPage(),
          const UserPermissionsPage(),
        ],
        builder: (context, pages, tabController) {
          return Scaffold(
            appBar: AppBar(
              title: Text(snapshot.data!.username),
              bottom: TabBar(
                controller: tabController,
                tabs: pages.map((p) => Tab(text: p.header)).toList(),
                onTap: (i) => context.goReplaceLast(pages[i].route), // my extension method for replacing only the last part of the current path
              ),
            ),
            body: TabBarView(
              controller: tabController,
              children: pages,
            ),
          );
        },
      );
    },
  );
}

Here I have my own TabNamedPagerBuilder which takes list of NamedPage. NamedPage is a mixin with route and header getters.
My pages are defined like UserRolesPage extends StatefulWidget with NamedPage.
This allows me to do things like pages.map((p) => Tab(text: p.header)).toList() or context.goReplaceLast(pages[i].route).

In this case if I was using server side generated tabs, I would fetch them in the UserBloc, generate a list of NamedPage and just pass them as a pages parameter to my TabNamedPagerBuilder.

This implementation works, but has the stack limitation described in the question linked above. That's where something like GoScopedRoute would be great for me.

Is it more clear now what I am trying to say? Does it still fit in this discussion?

[lulupointu]

I think for the tabs aspect you would indeed need what is described here. Especially if you are on the web.

However for the push/pop part I think what you really need is the equivalent to pushReplacement in Navigator 1 (I believe AutoRoute has this feature as well).
If this feature existed, then on GoTabbedController you would certainly have something like tabbedRouteController.pushReplacement(index) which you would need to use to make your UI.

[leoshusar]

Thanks! I think pushReplacement is the real solution for my whole problem.
I have now also found this cancelled pull request #193, so I'm just going to wait now for some pushReplacement alternative.

[csells]

Posting @lulupointu 's sample for reference as I ponder this proposal: https://github.com/lulupointu/go_router/blob/master/example/lib/tabbed_route.dart

[jamesblasco]

What about removing the need of manually creating a TabbedRouteController, adding an initialTabPath or initialTabIndex and passing the controller inside the navigatorBuilder?

GoTabbedRoute(
        path: '/',
        initialTabPath: '/red', // or initalTabIndex: 0,
        routes: TabItem.values.map(_coloredRoute).toList(),
        pageBuilder: (context, state, child) => MaterialPage<void>(
          key: state.pageKey,
          child: child,
        ),
        navigatorBuilder: (context, controller, child) => Scaffold(
          body: child,
          bottomNavigationBar: BottomNavigation(
            currentTabIndex: controller.currentIndex,
            onSelectTabIndex: (index) => controller.go(index),
          ),
        ),
      ),

[lulupointu]

Yes this seems like a great idea!

[jamesblasco]

I think I would separate the hidden-nested navigation from the GoTabbedRoute.

• GoTabbedRoute: Handles routes in a tab view
• GoNavigatorRoute: Adds a nested-navigation for the sub-routes

The best advantages of this is that it that both functionalities can be used separately.

GoTabRoute(
  path: '/',
  initialIndex: 0, 
  tabRoutes: [
    GoNavigatorRoute(
      path: 'books',
      initialLocation: '/'
      routes: [
        GoRoute(path: '/', pageBuilder: BookPageBuilder()),
        GoRoute(path: '/:bookId', pageBuilder: BookPageBuilder()),
        GoRoute(path: '/:bookId/edit', pageBuilder: BookPageBuilder()),
      ],
    ),
    GoNavigatorRoute(
      path: 'settings',
      initialLocation: '/'
      routes: [
        GoRoute(path: '/', pageBuilder: BookPageBuilder()),
        GoRoute(path: '/network', pageBuilder: BookPageBuilder()),
        GoRoute(path: '/edit_password/', pageBuilder: BookPageBuilder()),
      ],
    ),
  ],
  builder: (context, state, child, controller) => Scaffold(
    body: child,
    bottomNavigationBar: BottomNavigation(
      currentTabIndex: controller.currentIndex,
      onSelectTabIndex: controller.go,
    ),
  ),
)

[lulupointu]

I don't see how GoTabRoute would be used without GoNavigatorRoute.

Also GoNavigatorRoute looks like it's basically a GoTabRoute with a single tab.

[jamesblasco]

I just created an example of a possible GoTabRoute that does not use nested navigation. Very similar to the Revolut app

As the functionality of the nested navigation can be separated of the tab routes controlling, and the nested navigation has to be implemented specifically for each tabRoute, not as a global thing, I think it makes sense to have them as two separated functionalities that can be combined

[lulupointu]

Fine for your example but what if the user provides a route to a tabRoute?

For example, if we use your method and have the following (which is valid):

GoTabRoute(
  path: '/root',
  tabRoutes: [
    GoRoute(
      path: 'books',
      pageBuilder: BooksPageBuilder(),
      routes: [
        GoRoute(path: ':bookId', pageBuilder: BookPageBuilder()),
      ],
    ),
    GoRoute(path: 'settings', pageBuilder: SettingsPageBuilder()),
  ],
  routes: [
    GoRoute(path: 'other', pageBuilder: OtherPageBuilder()),
  ],
)

What should we do when the user is on /root/books/1 ?

[jamesblasco]

It would behave the same as:

GoRoute(
  path: '/root',
  routes: [
    GoRoute(
      path: 'books',
      pageBuilder: BooksPageBuilder(),
      routes: [
        GoRoute(path: ':bookId', pageBuilder: BookPageBuilder()),
      ],
    ),
    GoRoute(path: 'settings', pageBuilder: SettingsPageBuilder()),
  ],
  routes: [
    GoRoute(path: 'other', pageBuilder: OtherPageBuilder()),
  ],
)

The GoTabRoute would just allow to change between tabs by a given index and persist the state of the tab itself.

• If you are in /root and push /root/books/ it takes you to de desired tab
• If you are in /root/books/ and push /root/books/1 , the new route is pushed above it with the same root navigator

[csells]

@lulupointu I've been thinking a lot about this over the holiday break. The ideal solution would be that instead of nesting routes, you nest routers, specifically instances of GoRouter. I believe that Flutter has support for multiple routers and even the difference between the root router and child routers, although I don't know what that support entails. In light of our thinking wrt to making GoRouter a widget, it seems like every tab (for example) could have it's own GoRouter instance. That way, all of the things that people already understand about using a GoRouter instance at the root would apply when it comes to using a GoRouter as child widgets. Thoughts? Do you think that's feasible to implement?

[lulupointu]

I've been thinking about it since the question of multi stack routes arose. I think that, in practice, this is not a solution (at least for tabbed UI, which is the problem we are trying to solve) because:

1. GoRouter.of(context) would be context dependent
2. We would loose TabbedRouteController.currentIndex
3. We would loose TabbedRouteController.go
4. The state of the widgets would not be kept when switching back and forth

1. GoRouter.of(context) would be context dependent

GoRouter.of(context) would certainly reference the nearest GoRouter while GoRouter.of(context, useRoot=true) would reference to the root GoRouter. Now this is added complexity in and of itself but what if there are 3 GoRouter (For example a TabView inside a Scaffold with a BottomNavigationBar)? Referencing the GoRouter in the middle would be at best cumbersome.

2. We would loose TabbedRouteController.currentIndex

While not necessary TabbedRouteController.currentIndex is a nice addition, without it we would need to parse the url (which is GoRouter's job):

// WITHOUT TabbedRouteController
final currentIndex = GoRouter.of(context).match.startsWith('books') ? 0 : 1

This is pretty annoying because each time we add a new tab of we change the base url of a tab we need to update currentIndex, and there is no compiler warning since all the operations are based on strings

3. We would loose TabbedRouteController.go

While the previous examples where annoying at best, this one is a real pain and the reason GoTabbedRoute exists. Without it the user must manually track the last url of each tabs in order to switch between them. Here is how this can be achieved without TabbedRouteController:

class MyScaffold extends StatefulWidget {
  const MyScaffold({Key? key}) : super(key: key);

  @override
  _MyScaffoldState createState() => _MyScaffoldState();
}

class _MyScaffoldState extends State<MyScaffold> {
  // Initialize with the initial tab locations
  final List<String> tabsLastUrl = ['/books', '/settings'];

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    // Update each time [location] changes
    tabsLastUrl[_getCurrentIndex()] = GoRouter.of(context).location;
  }

  int _getCurrentIndex() => GoRouter.of(context).location.startsWith('/books') ? 0 : 1;

  @override
  Widget build(BuildContext context) => ...;
}

This is quite simple in the end but:

1. This is not intuitive
2. Needs to be maintained each time we add a tab/change a tabs url which is an initial location
3. All of this is free with TabbedRouteController

4. The state of the widgets would not be kept when switching back and forth

Lastly, and this might be the biggest point against nested GoRouter to solve tabbed routing: the state of the widget (or widget stack) in each tab cannot be preserved. Cannot is important because while the previous point always gave workaround, this one can simply not be achieved.

For a widget to keep its state, we need it to remain in the widget tree. If we have the following nested GoRouter:

GoRouter(
  initialLocation: '/books',
  routes: [
    GoRoute(
      path: 'books',
      pageBuilder: BooksPageBuilder(),
      routes: [
        GoRoute(path: ':bookId', pageBuilder: BookPageBuilder()),
      ],
    ),
    GoRoute(path: 'settings', pageBuilder: SettingsPageBuilder()),
  ],
),

When we navigate to books, SettingsPage is not in the widget tree, therefore its state is lost. This is the reason GoTabbedRoute is needed in the first place: it creates multiple Navigator side-by-side which are all put in the widget tree and which all handle their respective Page stack.

The "solution" would be to use multiple GoRouters side-by-side. The main challenge in this case is that each side-by-side GoRouter need to handles a different set of url while not knowing the other GoRouter. Beamer does that be asking you to manually activate the right Router and deactivate the others, here is an example. The interesting bit is the following:

final uriString = Beamer.of(context).configuration.location!;
currentIndex = uriString.contains('books') ? 0 : 1;

routerDelegates[currentIndex].active = true;
routerDelegates[1 - currentIndex].active = false;

This is a pain for the same reason that loosing TabbedRouteController.currentIndex is.
Not to mention that this scales very poorly if:

• The GoRouters are not used by the same widget
• There is a 3rd level of nesting

Maybe there is a better solution than the one Beamer offers but I have spend many hours thinking about it and never found one that I liked.

[jamesblasco]

I still don't understand why nested routers can't be decoupled from tab views

1. First allow nested routers in the widget tree.

2. A TabbedRoute that handles stacked routes, optionally persist the state of the offview pages and adds an inherited widget with the active/hidden status for each stacked page.

3. And supporting nested router inside a stack pages, it comes to this question: How would we handle this case?

     GoRouter
        Column
          children: 
             NestedGoRouter
             NestedGoRouter

If we can handle both inner routers at the same time like they where a single one. Then combining both features would be quite simple to handle with a private params inside GoRouter like:

active: context.dependOnInheritedWidgetOfExactType<GoTabRouteState>()?.active ?? true;

Regarding the context, for me the root GoRouter should be the only one that handles the route parsing and the sub routes are merely the presentation side like @esDotDev proposed in the other comment. So GoRouter.of(context) should always be the root router

[lulupointu]

Oh yes sorry I forgot to answer you. Anyway for what you wrote here here is my response.

A TabbedRoute that handles stacked routes, optionally persist the state of the offview pages

"persist the state of the offview pages" -> I don't know how this can be done without putting the Pages in the widget tree. The way I do it with GoTabbedRoute is basically:

IndexedStack(
  activeIndex: currentIndex,
  children: [
    Navigator(pages: [Page1Stack1, Page2Stack1]),
    Navigator(pages: [Page1Stack2]),
  ],
)

IndexedStack allows me to put both page stack in the widget tree at the same time (which causes their state to persist) while only showing one of them.

If I don't handle the Navigator in GoTabbedRoute, I don't see how I could persist the widgets state.

If we can handle both inner routers at the same time like they where a single one

This is the second big challenge. Side-by-side GoRouter do not know about each other so you can't act "like they where a single one". What you could do is report them in the root GoRouter but in that case why bother having nested router at all.

Conclusion

If you can solve both those challenges please share how and maybe I will change my mind on nested routers 😉

[esDotDev]

Lulu crushes it again :) Everything you say is totally true, and it all comes down to having an IndexedStack somewhere in the tree, that actually maintains state of 3 different Navigators, and this pattern just introduces a somewhat intractable level of complexity in Flutter. ie, it's never going to be great.

I think GoTabbedRouter is the best you're ever going to get, it

• manages the stack, keeping all routers in memory
• remembers your last visited tab, a nice quality of life feature
• creates the sibling routers boilerplate

This is a bit of a tangent, but I've sorta moved on to the thinking that restoring state is the much simpler problem to solve. If we can just re-purpose the StateRestoration API to have our pages restore themselves on-load, then we can just forget about the issue of having Stateful navigators and just wipe all this complexity off our plates. Have a single router, with routes that can restore their state, and call it a day. You get the UX you need in a more direct way. I guess this doesn't solve a variety of use cases though, like multiple push() calls into a specific navigator, in which case there is no avoiding something like GoTabbedRouter.

[lulupointu]

I guess this doesn't solve a variety of use cases though, like multiple push() calls into a specific navigator, in which case there is no avoiding something like GoTabbedRouter.

Good point, I thought about it but then forgot ^^ I edited the main post to state this limitation so that I don't forget again 😉

[esDotDev]

Regarding flutters behavior with multiple routers, the docs don't say a lot, but I guess they are pretty clear in what they do say:

A particularly elaborate application might have multiple Router widgets, in a tree configuration, with the first handling the entire route parsing and making the result available for routers in the subtree. The routers in the subtree do not participate in route information parsing but merely take the result from the first router to build their sub routes
https://api.flutter.dev/flutter/widgets/Router-class.html

So I guess we can think of child routers as just render surfaces, similar to the Output component in the new React router? We can move them down the tree, and they will just take care of rendering whatever the root router has matched?

[esDotDev]

fwiw, auto_route has a really nice implementation of this use case, AutoTabsRouter . and I think it is quite similar to the proposed TabbedGoRouter:
https://pub.dev/packages/auto_route#tab-navigation

Using an _IndexedStackBuilder under the hood, and some sort of inherited TabController that helps simplify switching of tabs.

[csells]

The lack of this feature is the #1 missing thing in GR, imo. I spent some time over the break digging into this issue enough to be able to really understand the need and get an intuition about the requirements of the implementation so I can actually judge @lulupointu's prototype. My ideal is still to be able to update GoRouter enough to be able to be instantiated at sub-locations in the widget tree to handle nested routing.

[esDotDev]

What I really like a about this proposed approach is this concept of tabRoutes and routes, and keeping them separate. These are really 2 distinct things, and this is definitely the most intuitive way I've ever seen them be declared. This allows both multiple stateful navigators, each with their own stack of pages that retain state, but a set of full-screen routes that can sit on top of all tabs. This has always been the "holy grail" imo, and I've never quite found a good way to express it with nav 2.0.

I like the idea of being able to nest the declared GR at sub-locations in the tree, but I think you'd still want the option to declare all the tabbed-routes and normal routs at the top. And also, no matter where you put the routing tables, some controller somewhere has to manage the logic of filling up a lazily-loaded IndexStack with multiple Routers, and changing them out based on an index value somewhere.

[esDotDev]

Maybe we can start with a simplified use case to explore what "pushing it down" would really look like.

Example site is 2 tabs, with 2 pages each, and there is 1 full-screen route. So 5 routes in total. The tabs should be stateful, and the full-screen routes should sit on top of all the tabs without wiping the tabs of all of their state.

In lulu's proposal, I believe this would look something like:

routes: [
  GoRoute(path: '/compose`)
]
tabRoutes: [
  GoRoute(path: '/inbox`, pageBuilder: inboxPage()
    routes: [
       GoRoute(path: 'important`, pageBuilder: importantPage()),
    ]
  ),
  GoRoute(path: '/settings`, pageBuilder: settingsPage(), 
     routes: [
       GoRoute(path: 'notifications`, pageBuilder: notificationSettingsPage()),
     ]
  ),
]

Each tabRoutes route, will be a new Navigator, stashed in IndexedStack and can be pushed down the tree using the .builder method. This is the magic that lets it hold state. External routes can sit on top of the tabbed ones, so this is yet another Navigator (I guess?)

This would end up generating the following valid "tabbed" pages which are stateful:

• /inbox
• /inbox/important
• /settings
• /settings/notifications

While also allowing /compose to be added on to the end of any of them, without wiping the underlying state:

• /inbox/compose
• /inbox/important/compose
• /settings/compose
• /settings/notifications/compose

Thinking on this for a bit it's quite interesting, and really allows you to compose 2 sets of routes together in a way that makes sense.

@lulupointu please let me know how if I have butchered your proposal :D

Q: How would we represent something like this if we instantiate the GR lower in the tree, or use multiple nested GR's? Maybe we can start from example usage code and work backwards to how it would work.

[lulupointu]

Tbh I don't see the difference between this and what I described with my initial comment ^^

[esDotDev]

Ya, I'm just describing again how your is working, to make sure I understand right, and also to break-down a concrete example so we can maybe explore other ways to express the same functionality. Srry for confusion.

[esDotDev]

@lulupointu I do have a couple Q's about the proposal after looking at it more closely:

• Why is /other not a valid path? Is it because the IndexedStack always needs something to render?
• Not sure Tabbed is the right naming, feels too mobile centric. This is just as likely to be TitleBar-ed or Sidebar-ed. I'd prefer something more agnostic, like GoRouteStack, with stackedRoutes: instead of tabbedRoutes

GoRouteStack(
  path: '/',
  controller: routeStackController,
  routes: [ GoRoute(path: '/other', ...) ]
  stackedRoutes: [
    GoRoute( ... ),
    GoRoute( ... ),
  ],
  builder: (context, state, child) => Scaffold(
    body: child,
    bottomNavigationBar: BottomNavigation(
      currentTabIndex: stackRouteController.currentIndex,
      onSelectTabIndex: _selectTabIndex,
    ),
  ),
)

[esDotDev]

I don't think this is the same thing, if user navigates to /other they would lose all state? If the stack is accepting either /other or $path/other it could decide to keep the route stack rendered underneath if a path is included?

[esDotDev]

Not sure I like it either, just wanted to make sure I understood the rationale.

[lulupointu]

I don't think this is the same thing, if user navigates to /other they would lose all state?

Not if you use context.push I think

[esDotDev]

Oh right, forgot about that :D well that's pretty cool

[leoshusar]

IMO having separate GoRoute(path: '/other') is fine.

And for the GoRouteStack(path: '/'), what about auto redirect to the first tab route? Or have an option to set it?

GoRouteStack(
  path: '/',
  // mainRoute: null -> auto redirect to '/inbox', because it's first
  // mainRoute: '/settings' (or just 'settings'?) -> auto redirect to '/settings'
  stackedRoutes: [
    GoRoute(path: 'inbox'),
    GoRoute(path: 'settings'),
  ],
)

[esDotDev]

Thinking through the 'push the routers down' approach, it seems like one approach that might work well is something like:

• The top-most Routers navigator is discarded / ignored
• Child DeferredGoRouters, or GoRouterOutlet create their own Navigators, but look up the root GoRouter, and ask it for a pageStack.
• The child routers+navigators could be stashed in IndexedStack to theoretically maintain their state
• Switching of the tabs (changing navigators) would be handled imperatively by a top-level stateful view and some string parsing

Maybe this can all be made automatic by making GoRouter a widget, and then just having them enter "deferred mode" when they see an ancestor router. It seems it would be nice to be able to declare routes either at the sub-router or the root-router level.

[esDotDev]

In terms of what that would actually look like, it's something in the realm of:

GoRouter(
  routes: [
    GoRoute(path: '/inbox`, pageBuilder: inboxPage()
      routes: [
         GoRoute(path: 'important`, pageBuilder: importantPage()),
      ]
    ),
    GoRoute(path: '/settings`, pageBuilder: settingsPage(), 
       routes: [
         GoRoute(path: 'notifications`, pageBuilder: notificationSettingsPage()),
       ]
    ),
  ],
  navigatorBuilder: (_, __) => MainView() // top level navigator is ignored
);

Then in main_view.dart:

int currentIndex = url.startsWith('/settings')? 1 : 0;
return IndexedStack(
  currentIndex: currentIndex,
  children: [
      GoRouter.deferred(),  // doing something like Navigator(pages: GoRouter.of(context).getPageStack())
      GoRouter.deferred(),
  ]
)