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

animations

Description

IMPORTANT NOTE: this is an item that needs research/prototype, there is no guarantee that the solution described in this ticket would work.

Currently, in order to enable animations in a project, you can use the provideAnimations() function. The function brings the necessary providers and as a result, the code is included eagerly (the code gets added to the main bundle). However, in vast majority of cases, animations happen on user interaction and animations code is not needed immediately on page load. It'd be beneficial for initial page load if animations code can be deferred and be loaded asynchronously (i.e. code is excluded from the main bundle). There is also a related issue #20002, which talks about NoopAnimationsModule bringing a lot of code too. There is a chance that with some refactoring we can drop direct references to symbols that represent animation providers (instead, making them tree-shakable), so the size of the NoopAnimationsModule may go down.

It'd be great to explore a solution like this:

• we can consider adding a new function (like provideAnimationsAsync)
• the function would register a renderer (similar to how it works today), but the renderer would have the following logic:
  • by default it delegates to the currently configured renderer
  • if there is a component that has animations metadata (this info should be available at runtime) being initialized, start loading animations code (via dynamic import). We could consider doing it within requestIdleCallback.
  • once the code is loaded, route calls to that loaded renderer (instead of delegating to the parent renderer)
• this change would also require making SHARED_ANIMATIONS_PROVIDERS (here) tree-shakable, so that there are no direct references to the symbols that bring a lot of code alongside with them. This item could also improve tree-shaking for the NoopAnimationsModule (which shouldn't reference those symbols, hence they should be tree-shaken away). This is probably the first item to look at, because if it's not feasible, other improvements describe above would bring only minor benefits (and may not worth adding extra complexity).

Note: the described approach is not entirely new in the codebase, we perform a similar lazy-loading for Hammer library, see here. However, dynamic renderer delegation is something that we'd need to explore (there are no examples in the codebase).

// cc @jessicajaniuk @JeanMeche in case you have some thoughts on this