Provide multiple providers from the single provision

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

core

Description

Hi, I wonder whether is it possible to add an option to provide multiple providers by single provision; this way it is possible to make the app more customizable and inject providers on any level - through useFactory and dependency, for example. The important thing is that injectors create a tree, so other dependencies visibility matters at this point - that is why providing something further in the tree in a ‘lazy’ manner is feasible - now you should somehow fetch the lower injector and create the new one based on it, or make some nasty delegation.

Proposed solution

Let us assume that there is the token TOKEN_PROVIDER which should provide Provider[] - this way you could return different providers based on some condition, or just pass these ‘created’ before - like for Injector.create().

Alternatives considered

As mentioned in the description now there is a possibility to provide some dummy-delegate implementation and fill it later, but it still does not solve the problem in total, because it could be shared between different nodes in the injector tree.

[Azbesciak]

But the case is that the config need to be injected, or providers from ‘above’, not to mention about some injected factory which provides another providers.

there’s a sufficiently strong use case for this in Angular

What does it mean? AI think that if you provide a tree-based injector, and at the same time, there is a possibility to use multiple providers of the same type, this may be required for better flexibility - at least I missed it for the last 5 years, for the last 3 I made some workarounds, but now I am into the corner with not perfect solutions - it looks like it must be solved on the framework level.

I supose that most of your users use just DI as injecting type, maybe even 90% even do not use multi providers, so in fact this may be not the most keen feature. But please be aware of the rest of your users - they probably write their own proxy frameworks on this if they need something. Please, remember also about their needs.

[marcinmilewicz]

This is exactly what I’ve looked for recently.