fix(core): remove nested views from registry when root is destroyed #41894
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a follow-up to angular#41358 where my assumption was that `destroyLView` would be called for all views down the tree, but it turns out that it only gets called for the root and we actually call `cleanUpView` for the descendants. The result is that some views might not be removed from the registry after they're destroyed. These changes move the `unregisterLView` call into `cleanUpView` instead.
crisbeto
added
action: review
AndrewKushnir
requested review from
AndrewKushnir
and removed request for
atscott
AndrewKushnir
approved these changes
Apr 30, 2021
AndrewKushnir
added
action: presubmit
crisbeto
added a commit
to crisbeto/angular
that referenced
this pull request
Apr 30, 2021
These changes combine angular#41358 and angular#41894. Currently we save a reference to an `LView` on most DOM nodes created by Angular either by saving the `LView` directly in the `__ngContext__` or by saving the `LContext` which has a reference to the `LView`. This can be a problem if the DOM node is retained in memory, because the `LView` has references to all of the child nodes of the view, as well as other internal data structures. Previously we tried to resolve the issue by clearing the `__ngContext__` when a node is removed (see angular#36011), but we decided not to proceeed, because it can slow down destruction due to a megamorphic write. These changes aim to address the issue while reducing the performance impact by assigning a unique ID when an `LView` is created and adding it to `__ngContext__`. All active views are tracked in a map where their unique ID is used as the key. We don't need to worry about leaks within that map, because `LView`s are an internal data structure and we have complete control over when they are created and destroyed. Fixes angular#41047.
|
Closing in favor of #41908. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a follow-up to #41358 where my assumption was that
destroyLViewwould be called for all views down the tree, but it turns out that it only gets called for the root and we actually callcleanUpViewfor the descendants. The result is that some views might not be removed from the registry after they're destroyed.These changes move the
unregisterLViewcall intocleanUpViewinstead.