Rearchitect Router so it's more modular

Which @angular/* package(s) are relevant/releated to the feature request?

router

Description

The Angular router’s current architecture is problematic for a couple big reasons:

• It is not extensible. Developers cannot easily extend or change the Router’s functionality to support features that would be useful to their applications. Instead, these features have to be built in to the core Router code and exposed through some endpoint (i.e. RouteReuseStrategy, some option on ExtraOptions which is used as an switch in the internal code, etc.)
• It is not tree shakeable. Due to its non-modular nature, almost all features (lazy loading, guards, resolvers) are generally baked in to the Router’s internals unless explicitly configurable through a Strategy that can provide a no-op implementation. Simple applications that do not use these features still incur the bundle size cost.

Proposed solution

Because of the above two problems, we’re often quite limited on what features we can implement. The router should be rearchitected with the following goals in mind:

• Tree-shakeability
• More configurable features, such as
  • #24187
  • #40577
  • #10556 / #24956
  • #16416
  • Configurable browser history management, for example
    • Ability to use the upcoming App History API
    • #42915
    • Ability to fix issues like #13586 without having to wait for the baked-in fix
• General ability to use @angular/router to build custom routing solutions, which will likely require exposing more of the router internals such as:
  • #38951
  • #25630 / #24069

Alternatives considered

N/A

[micru]

Any news on this? Would be really great to have more flexibilty with the router, especially to change the execution order of guards and resolvers as its often nearly impossible use them both in conjucation as it should be

[atscott]

@micru It’s on our radar and I’m trying to slowly chip away at some smaller complexities in the router that would make this more difficult to accomplish. Some of these items include #45735, #45240, #45877. Special cases and unpredictability in how the Router internals operate make it harder to expose swappable parts because it’s harder to match the expectations or even know what those are.

There’s no additional information at the moment though. We haven’t started work on taking a deep dive into what APIs we want to make pluggable.