Remove the usage of ChainRouter by default

If this works +1 - less onion skins. And it is easy for a project to use it if they need it.

We should really kill as much of this code as possible - anyone who really needs to nest or chain can add those back

If I understand correctly ChainRouter just prioritize list of routers and loops through chained router. Also that ChainRouter provides DynamicRouter and uses NestedMatcher.

Do we need to use 3 step or multi-step matching process or are we using prioritize list of router in core? I have quickly scanned core for the Routing CMF and I didn't find usage of ChainRouter in core except in AccessAwareRouter.php class. If we decide to remove ChainRouter then does that mean that we need to remove DynamicRouter and NestedMatcher from core. As for right now LazyRouteFilter and UrlMatcher classes are using NestedMatcher.
I am wondering if it's too late to remove this from core. I had a conversation on IRC and suggestion was to move CMF into an optional module enabled by default/hook_update and later drop this in d9.

I think removing this from core would be a good idea if we aren't using it and don't know if contrib would have any need to use ChainRouter. I would like to work on this issue after getting approval from routing maintainer.

I hope we can keep this issue in scope. People don't understand what CMF is doing, they don't understand what the NestedMatcher is really doing, but well, the ChainRouter here is doing effectively nothing by default at the moment so I think we should drop it.

Yes, that is the issue that very few people understand routing in general and layers associated with it which is sad. My question is - Do we need to get rid of CMF and use default routing from Symfony or just drop ChainRouter from core? Also, this seems like too late to go in 8.0.x but could be done in 8.1.x

ChainRouter is just a chain-of-responsibility wrapper. Removing it from the pipeline SHOULD be possible, but that doesn't buy us much, IMO.

My concern with removing it from the default config is that if someone wants to re-enable it in order to add a faster pre-router (which is what ChainRouter is for), it's non-obvious how to do so, especially if multiple modules try to do so. We've been discussing that already, eg #2471234-11: Create a ChainedRouteProvider which subclasses RouteProvider but could return early for most common routes.

That said, as I also note in that issue I'm not certain that ChainRouter still works, given the amount of work we have DynamicRouter and NestedRouter doing. Which is why removing those is completely off the table. It may be possible to refactor the pipeline in the router to have fewer moving parts, but that would be so not RC-safe it's not even funny. The availability of route filters and enhancers, eg, is part of our API, and we're using those in core, and I know some contribs are planning to do so. Eg, #2305199: Create a route for every variant and use a "route filter" to apply selection rules. Changing away from NestedMatcher/DynamicRouter is D9 material.

What I'd really like to see us do is try to use ChainRouter and make sure it's still viable. Could we still build a useful and worthwhile early/fast router (which doesn't have to use DynamicRouter or NestedMatcher)? If not, then we cry a little and disable ChainRouter as it doesn't buy us anything anyway. If we can, then maybe we should go ahead and use it. :-) (Or at least keep it around to prove that sites can have custom optimized routers.)

Well ChainRouter is a stack of routers. It's the same chain approach we use in a half dozen places now.

Enhancing the compiler pass to automatically insert it sounds interesting. I'm not opposed to that, although I'm a bit concerned at making it more non-deterministic, especially for debuggers. Really, if you're messing with the router services you need to really know what you're doing.

That said, as I also note in that issue I'm not certain that ChainRouter still works, given the amount of work we have DynamicRouter and NestedRouter doing.

I am not sure how to use ChainRouter and I am sure others might be wondering about the practical usage of this. Could someone please given an example how to use it so more than one person can test to see if it works or not? It will help us understand better.

It may be possible to refactor the pipeline in the router to have fewer moving parts, but that would be so not RC-safe it's not even funny.

We need to document when ChainRouters can be use or if NestedMatcher, DynamicRouter would be enough.

Well ChainRouter is a stack of routers. It's the same chain approach we use in a half dozen places now.

Can you give example? I didn't see ChainRouter anywhere in core except in AccessAwareRouter.php unless I am missing something.

This here fixes some of the failures but yeah, as we talked on the criticals meeting, this is not something we will do before 8.0.x and will require a BC layer in 8.1.x, but adding it conditionally can land later.

Has it been decided to remove this from core?

The onion is just for access aware router, which is an entirely separate question. I was actually quite against that thing, actually, but didn't have the energy to fight it.

I don't understand dawehner's comment either. I was not in any discussion about deciding what to do here. My statements in #19 and #21 still stand.

Aside from the potential route recompilation, what's the issue?

Ah, hm. If we're fetching from RouteProvider anyway, do we even gain that much? It would still be a DB hit, unless we had an alternate RouteProvider for the alternate router that had a handful of compiled-to-PHP routes.

+1

You are very mean @dawehner! My heart started racing, when I saw this issue green in the tracker... ;-)