[Discussion] Usefulness of the Switch

This is a kinda spin-off from #5785.

Current state

Currently, the react-router is built so we can have routes all over the app and don’t bother much with static routing configuration. That’s definitely great concept, but there is one flaw.

The Switch most common use case is to have a fallback route that should be rendered when nothing else matches. Apparently, that doesn’t work well with dynamic routing nature. It forces us to have all routes in a single place again to try match against all of them till it reaches the fallback one.

Another issue is in case I simply want to wrap a single Route to another component because there is some additional logic within the route that would clutter whole Switch

<Switch>
  <TooSmartRoute /> // notice no props here, everything is inside the component
</Switch>

Such route is always matched by the Switch simply because it’s lacking path in the props.

Solution?

Letting Switch to traverse the whole tree of children to find a match is definitely a bad idea.

Honestly, I don’t have any proven solution, just a hot idea. It would be something along the lines of having a new component called eg. Fallback which would accept prop of the fallback route.

<Fallback route={<NotFound />}>
  // ... some deeply nested routing
</Fallback>

This component would just render everything without any traversal. When some Route would match, it would internally use context to inform Router about that. Then the Fallback would be able to pick up that information (not sure if that’s possible actually) and render fallback route if there wasn’t any match.

Any other thoughts/ideas?

[timdorr]

While you might be able to build something like this now, this will essentially be impossible when async rendering drops in React. Namely because you can never know when the state of all Routes within a tree are fully materialized. Routes can pop in and out of the tree at any moment asynchronously. And the lifecycle methods to synchronize them (cWM, cWRP) are going away. So you’ll end up with weird synchronization issues, mostly in the form of trailing content in the DOM while the render loop finishes processing and reconciling.

This is going to be an interesting transition for most apps and libraries, where certain guarantees are no longer possible.

Really the only solution here will be to go back to the old way of doing things via a top-level route configuration, aka react-router-config. That can manage the config internally and stays synchronous within its own lifecycle (async doesn’t do any preemption). I’d like to get it out of beta and close out things like #5429 and #4962. It can solve a lot of these problems, but it needs some more superpowers to be truly useful.

[edkalina]

It was announced that React Call Return won’t be released. So I’ve implemented similar pattern as react-aggregation library.

Here is concept of new Switch implemented with react-aggregation. It allows to nest routes any way you want.

What do you think about this? @FredyC @timdorr @jamesplease