React Router 6

[esDotDev]

Just had a look through the new react router, it's pretty neat how similar it is to go_router:
https://reactrouter.com/docs/en/v6/getting-started/overview

Good sign when you see everyone condensing towards the same point in the API design!

Just posting here for visibility, and maybe it will spark some inspiration or crystallize some thinking. It has some rules and features that are pretty interesting:

• Most Specific Match Rule - They have a rules that "most specific match wins", which I guess go_router does as well, but I think go_router takes the first set of routes it sees, whereas they compare all possible matches, and then take the most specific match. This allows them to do stuff like put a <Route path="*" element={<NoMatch />} /> for a 404 error. It matches everything, but is also least specific, so it always goes last. Similarly, a link to family/create is considered more specific than family/:familyid. This frees up the routes table from caring so much about order of declaration or parent/child structure.
  https://reactrouter.com/docs/en/v6/getting-started/overview#configuring-routes
• Index Routes - Basically the same as the incoming navigationBuilder at the route level. But calling them 'index routes', with a path of "/" feel very intuitive: https://reactrouter.com/docs/en/v6/getting-started/overview#index-routes, kinda neat.
• Relative Links - Relative <Link to> values (that do not begin with a /) are relative to the path of the route that rendered them.
  https://reactrouter.com/docs/en/v6/getting-started/overview#relative-links
• Multiple Sets of Routes - This is really interesting. You can declare the same path, at 2 different spots in the tree, basically nesting a set of routes anywhere you want in your app: https://reactrouter.com/docs/en/v6/getting-started/overview#multiple-sets-of-routes They give a really nice example of how you could use this to change your side bar, depending what path your main content area has navigated to.
• Descendant routes - You declare a route with foo/bar/* at the top, and then further down the tree, you finish it off.
  https://reactrouter.com/docs/en/v6/getting-started/overview#descendant-routes

[csells]

@esDotDev thanks for the thoughtful dig into another routing system! There are lots of interesting ideas here. I do resist adding new ideas to GR unless there is also new functionality unlocked. Having multiple ways of doing the same thing is a cognitive load for the user that I'm trying to avoid as much as possible. That said, for things that GR can't already do, I'd like to know more.

re: most specific match rule: go_router only allows you to match a single rule. I got tired of arranging my table according to the order I wanted things to match, so I got rid of that altogether. If there's multiple matches, it's an error that's reported to the developer.

re: index routes: you can do that today via redirection, e.g. /family => /family/[first-family-id], or by just providing a builder that builds what the "index" route would build.

re: relative links: I like this idea but I'm not quite sure how to implement it...

re: multiple sets of routes: this is interesting, too, although I'm not quite sure what problem it solves. How do you think this would work in the world of GR?

re: descendant routes: this is an interesting way to spread routing -- particularly nested routing -- into different parts of the app. this is still a nut I'd like to crack w/ GR.

[esDotDev]

Ya these are interesting, I'm trying to think of how they look in Flutter.

The key abstraction in this approach, is the idea that you can push the matching route downwards into the tree, using the <Outlet> component.

I guess this Outlet does something like:

Widget build(){
   return GoRouter.of(context).navigator;
}

And you can stick this GoRouterOutlet() anywhere you want in your app allowing you to easily to move the content of your Router into different scaffolds. It's like the inverse of using a builder. Instead of (_, navigator) => MyScaffold(child: navigator) it's more like:

class MyScaffold extends StatelessWidget{
  Widget build(_) => Column(children: [
     Text('My App Title'),
     Expanded(child: GoRouterOutlet()) // <- equivalent of 'navigator' in the builder above
  ])
}

I'm not sure if it really provides anything the navigatorBuilders do not. It decouples scaffolding from the Router itself, but I'm not sure that is necessarily a good thing. It's super flexible, but also feels like it could be hard to debug when things break.

Then they combine that, with the ability of having multiple Routes tables spread around the app. So then you can define multiple sets of route tables, each with their own Outlet, enabling some interesting designs. For example,

• your TitleBar could have one set of routes, determining what type of title / buttons to show
• your LeftSideMenu could have another set of routes, determing which menu it shows,
• and then you could have a 3rd routing table, which is your main content area, and it has all your routes defined.

I'm not sure how this last bit looks in Flutter. I guess it is basically just some sort of WidgetSwitcher, that is tied into the current path? We can do this now with imperative code, for example:

// Inside of `LeftSideMenu`
if(currentPath.contains('/users')) return UsersMenu();
if(currentPath.contains('/settings')) return SettingsMenu();
return SizedBox.shrink();

// Or, inside of `TitleBar`
if(currentPath.contains('/users')) return Text('Users');
if(currentPath.contains('/settings')) return Text('Settings');
return Text('My App Title');

Again, not sure the declarative approach enables anything we can't do imperatively, but interesting design nonetheless.

[esDotDev]

I could envision something like this being pretty handy:

Widget build(_) => GoRouterWidgetSwitcher(
  transitionBuilder: ...
  routes: {
    '/users/*' :  Text('Users'),
    '/settings/*' :  Text('Settings')
  }
));

I think that fundamentally gets to what they are doing, and is a nice way to declaratively react/bind your UI to the current app path.

We could combine that with a GoRouterWidgetSwitcherOutlet which would let us push the current match downwards, for example:

Widget build(_) => GoRouterWidgetSwitcher(
  child: _TitleBar()
  routes: {
    '/users/*' :  Text('Users'),
    '/settings/*' :  Text('Settings')
  }
)!;
...
class _TitleBar extends StatelessWidget {
  Widget build() => Padding(
    padding: EdgeInsets.all(24),
    child: GoRouterWidgetSwitcherOutlet()) // <- The outlet renders the current match of the closes GoRouterWidgetSwitcher
}

But again...is this any better than just having an optional builder? I guess both have their use cases.