You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
NgComponentOutlet should allow module injectors in addition to component injectors #18387
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
Current behavior
NgComponentOutlet allows the user to specify the injector to be used when instantiating and inserting a component using an NgModuleFactory, but it currently assumes that the injector being passed is a component injector, not a module injector. This leads to restrictions when the injector passed to NgComponentOutlet has additional services added via ReflectiveInjector.resolveAndCreate, as the module containing the component cannot access these providers. This limitation appears to have been introduced with pull request #15044 and occurs because of the assumption at https://github.com/angular/angular/blob/master/packages/common/src/directives/ng_component_outlet.ts#L89.
Expected behavior
NgComponentOutlet should either detect or allow the specification of whether the injector provided is a component or module injector. If it is a component injector, the behavior should remain unchanged. If it is a module injector, then NgComponentOutlet should not attempt to retrieve the NgModuleRef's injector using the custom injector, as this retrieves the new module injector's parent, discarding any newly added providers.
What is the motivation / use case for changing the behavior?
This limitation prevents a parent component from dynamically loading several components with different custom providers accessible at the module level. This introduces unnecessary complexity for users writing dynamically loaded modules, as providers created via ReflectiveInjector.resolveAndCreate within the parent component are only accessible to providers in the dynamic component's component injector tree (not the module injector tree).
For example, if I declare a service as a provider in my custom module, it will not be able to access any additional providers I create for the NgComponentOutlet's injector via ReflectiveInjector.resolveAndCreate. Only providers within the component tree can access them.
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
Activity
amitport commentedon Feb 13, 2020
any progress?
angular-robot commentedon Jun 4, 2021
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
amitport commentedon Jun 4, 2021
Github Voting is not and shouldn't be a proxy to the issue's importance of to the community.
angular-robot commentedon Jun 24, 2021
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
angular-automatic-lock-bot commentedon Apr 14, 2022
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.