Skip to content

fix(core): call ngOnDestroy for tree-shakeable providers #28943

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

JoostK
Copy link
Member

@JoostK JoostK commented Feb 23, 2019

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.io application / infrastructure changes
  • Other... Please describe:

What is the current behavior?

Issue Number: #28927

Prior to this change, any provider that was independently resolved using
its InjectableDef would not be considered when destroying the module it
was requested from.

What is the new behavior?

This commit provides a fix for this issue by storing
the resolved provider in the module's list of provider definitions.

Additionally, a test for Ivy's module injector was added to prevent
regressing on this behavior going forward.

Does this PR introduce a breaking change?

  • Yes
  • No

Sorry, something went wrong.

Prior to this change, any provider that was independently resolved using
its InjectableDef would not be considered when destroying the module it
was requested from. This commit provides a fix for this issue by storing
the resolved provider in the module's list of provider definitions.

Fixes angular#28927
This test verifies that Ivy's module injector does not suffer from
angular#28927 to prevent regressing on this behavior going forward.
@JoostK JoostK requested a review from a team as a code owner February 23, 2019 15:26
@@ -109,7 +109,7 @@ export function resolveNgModuleDep(
} else if (
(injectableDef = getInjectableDef(depDef.token)) && targetsModule(data, injectableDef)) {
const index = data._providers.length;
data._def.providersByKey[depDef.tokenKey] = {
data._def.providers[index] = data._def.providersByKey[depDef.tokenKey] = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this can not make data._def.providers sparse, as the indices should be aligned. I'd like a second opinion on this though :)

@JoostK
Copy link
Member Author

JoostK commented Feb 23, 2019

/cc @alxhub

@JoostK JoostK changed the title Module ondestroy fix(core): call ngOnDestroy for tree-shakeable providers Feb 23, 2019
@benlesh benlesh added area: core Issues related to the framework runtime comp: ivy labels Feb 23, 2019
@ngbot ngbot bot added this to the needsTriage milestone Feb 23, 2019
@benlesh benlesh removed the comp: ivy label Feb 23, 2019
@mhevery mhevery added action: merge The PR is ready for merge by the caretaker target: major This PR is targeted for the next major release labels Apr 4, 2019
@mhevery
Copy link
Contributor

mhevery commented Apr 4, 2019

@IgorMinar IgorMinar closed this in 30b0442 Apr 5, 2019
IgorMinar pushed a commit that referenced this pull request Apr 5, 2019
…28943)

This test verifies that Ivy's module injector does not suffer from
#28927 to prevent regressing on this behavior going forward.

PR Close #28943
DeveloperFromUkraine pushed a commit to DeveloperFromUkraine/angular that referenced this pull request Apr 11, 2019
Prior to this change, any provider that was independently resolved using
its InjectableDef would not be considered when destroying the module it
was requested from. This commit provides a fix for this issue by storing
the resolved provider in the module's list of provider definitions.

Fixes angular#28927

PR Close angular#28943
DeveloperFromUkraine pushed a commit to DeveloperFromUkraine/angular that referenced this pull request Apr 11, 2019
…ngular#28943)

This test verifies that Ivy's module injector does not suffer from
angular#28927 to prevent regressing on this behavior going forward.

PR Close angular#28943
wKoza pushed a commit to wKoza/angular that referenced this pull request Apr 17, 2019
Prior to this change, any provider that was independently resolved using
its InjectableDef would not be considered when destroying the module it
was requested from. This commit provides a fix for this issue by storing
the resolved provider in the module's list of provider definitions.

Fixes angular#28927

PR Close angular#28943
wKoza pushed a commit to wKoza/angular that referenced this pull request Apr 17, 2019
…ngular#28943)

This test verifies that Ivy's module injector does not suffer from
angular#28927 to prevent regressing on this behavior going forward.

PR Close angular#28943
@hspier
Copy link

hspier commented Jun 4, 2019

@mhevery @JoostK Any chance of having this PR applied to the 7.2.x release? Given IE11 has trouble reclaiming memory on active observables (which are not cancelled with the takeUntil in ngOnDestroy) this is a really critical issue. Also, switching back all services spread across several libraries (including 3rd party one such as Material) to the forRoot approach is quite a significant amount of work.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: core Issues related to the framework runtime cla: yes target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants