fix(core): ViewContainerRef.createComponent should consult module injector when custom one is provided

[AndrewKushnir]

Before Ivy, it was only possible to call the ViewContainerRef.createComponent function with the ComponentFactory as the first argument. An instance of a ComponentFactory resolved via ComponentFactoryResolver contained a reference to an NgModule where the component is declared. As a result, the component maintained a DI connection with the module injector tree (by retrieving an instance of NgModuleRef internally), even when the custom injector was provided (we try to find a token in a custom injector first and consult module injector after that).

With Ivy, we expanded the ViewContainerRef.createComponent function API to support direct references to the Component classes without going through the factory resolution step. As a result, there was no connection to the NgModule that declares the component. Thus, if you provide a custom injector, this is the only injector that is taken into account.

This commit updates the logic for the factory-less case to try retrieving an instance of an NgModuleRef using the DI tree which ViewContainerRef belongs to. The NgModuleRef instance is then used to get a hold of a module injector tree. This brings the factory-less and factory-based logic to a consistent state.

Closes #44897.

PR Type

What kind of change does this PR introduce?

• Bugfix

Does this PR introduce a breaking change?

• Yes
• No

[pkozlowski-opensource]

Drive-by-comment (sorry, just trying to understand things better).

This commit updates the logic for the factory-less case to try retrieving an instance of an NgModuleRef using the DI tree which ViewContainerRef belongs to. The NgModuleRef instance is then used to get a hold of a module injector tree. This brings the factory-less and factory-based logic to a consistent state.

My understanding is that previously a component type would maintain (through a component factory resolver) a connection to a NgModule where the component being instantiated was declared. It mens that it could "see" providers from the declaring module. In other words - a component could see providers from the declaration place.

If I understand correctly, based on the comment, we are now trying to figure out NgModuleRef based on the insertion point (this is how I'm interpreting "using the DI tree which ViewContainerRef belongs to").

In many cases the declaration and insertion injector hierarchies will "see" the same providers but it is not always the case, ex.: for lazy-loaded modules. If my reasoning it correct a dynamically instantiated component still wouldn't "see" providers from the lazy module, right? (unless a lazy-loaded NgModuleRef is passed-in explicitly). It is reasonable, I'm just trying to understand if this is the same behaviour as with ComponentFactoryResolver version of things?

[alxhub]

@pkozlowski-opensource absolutely accurate summary!

My understanding is that previously a component type would maintain (through a component factory resolver) a connection to a NgModule where the component being instantiated was declared. It mens that it could "see" providers from the declaring module. In other words - a component could see providers from the declaration place.

This (as you probably know) was absolutely true in View Engine, but only conventionally true in Ivy.

In View Engine, you had to use a CFR from the NgModuleRef (injector) from an NgModule which declared/imported the component you were trying to resolve. Doing otherwise would result in the CFR not being able to resolve the component to a factory.

In Ivy, any CFR can give you a factory for any component - with an NgModuleRef tied to the CFR's provenance that may or may not be the "right" one for the component in question. Thus, to use the API correctly, users have to know to get a particular CFR from the right injector (and nowhere in our documentation is this explained).

I think this ship has sailed, to be honest - the framework no longer enforces the component-NgModule relationship, and we're moving towards a world without ComponentFactory at all. Instead, we should make sure that we document the right conventions around components and NgModules.

If I understand correctly, based on the comment, we are now trying to figure out NgModuleRef based on the insertion point (this is how I'm interpreting "using the DI tree which ViewContainerRef belongs to").

I view this approach as using the DI tree which you would've gotten if you naively injected ComponentFactoryResolver and resolved the component to a factory on demand. This does the "right thing" in the standard application case and in lazy-loaded routes. It's insufficient in cases where you loaded the component reference from some "out-of-tree" location - but in that case, Ivy's implementation of CFR wouldn't help either - it's on the user to make sure that they pass in the right NgModuleRef in that case.

[pkozlowski-opensource]

Thnx @alxhub for the comment, it completely matches my understanding / mental model. Key highlights for me:

Thus, to use the API correctly, users have to know to get a particular CFR from the right injector (and nowhere in our documentation is this explained).

Yep, probably not many people are aware of it. In my head it translates to: it is on users to maintain "component / provider" association "declared" in NgModule. With ivy this association is gone and needs to be re-created "manually".

I think this ship has sailed, to be honest - the framework no longer enforces the component-NgModule relationship, and we're moving towards a world without ComponentFactory at all. Instead, we should make sure that we document the right conventions around components and NgModules.

Agree. And the only long-term strategy, IMO, is to work towards the World without providers defined on a NgModule level....

It's insufficient in cases where you loaded the component reference from some "out-of-tree" location - but in that case, Ivy's implementation of CFR wouldn't help either - it's on the user to make sure that they pass in the right NgModuleRef in that case.

Agreed.

[AndrewKushnir]

Global Presubmit.

[dylhunn]

This PR was merged into the repository by commit 822439f.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}