fix(core): Avoid refreshing a host view twice when using transplanted…#53021
Closed
atscott wants to merge 1 commit intoangular:mainfrom
Closed
fix(core): Avoid refreshing a host view twice when using transplanted…#53021atscott wants to merge 1 commit intoangular:mainfrom
atscott wants to merge 1 commit intoangular:mainfrom
Conversation
345594b to
e0cc73b
Compare
e0cc73b to
dd64c6c
Compare
alxhub
reviewed
Dec 5, 2023
Member
alxhub
left a comment
There was a problem hiding this comment.
How about instead, everywhere we call refreshView, we switch to using detectChangesInternal but set the Dirty flag beforehand?
07b6876 to
cd92806
Compare
alxhub
reviewed
Dec 6, 2023
Member
There was a problem hiding this comment.
Given the commit message talks about the importance of RefreshView as opposed to Dirty here, can you document that in a comment?
alxhub
approved these changes
Dec 6, 2023
… views This change fixes and issue where the expectation was that change detection always goes through `detectChangesInView`. In reality, `detectChangesInternal` directly calls `refreshView` and refreshes a view directly without checking if it was dirty (to my discontent). This update changes the implementation of `detectChangesInternal` to actually be "detect changes" not "force refresh of root view and detect changes". In addition, it adds the refresh flag to APIs that were previously calling `detectChangesInternal` so we get the same behavior as before (host view is forced to refresh). Note that the use of `RefreshView` instead of `Dirty` is _intentional_ here. The `RefreshView` flag is cleared before refreshing the view while the `Dirty` flag is cleared at the very end. Using the `Dirty` flag could have consequences because it is a more long-lasting change to the view flags. Because `detectChangesInView` will immediately clear the `RefreshView` flag, this change is much more limited and does not result in a different set of flags during the view refresh.
cd92806 to
3fac113
Compare
Member
|
This PR was merged into the repository by commit 2565121. |
alxhub
pushed a commit
that referenced
this pull request
Dec 7, 2023
… views (#53021) This change fixes and issue where the expectation was that change detection always goes through `detectChangesInView`. In reality, `detectChangesInternal` directly calls `refreshView` and refreshes a view directly without checking if it was dirty (to my discontent). This update changes the implementation of `detectChangesInternal` to actually be "detect changes" not "force refresh of root view and detect changes". In addition, it adds the refresh flag to APIs that were previously calling `detectChangesInternal` so we get the same behavior as before (host view is forced to refresh). Note that the use of `RefreshView` instead of `Dirty` is _intentional_ here. The `RefreshView` flag is cleared before refreshing the view while the `Dirty` flag is cleared at the very end. Using the `Dirty` flag could have consequences because it is a more long-lasting change to the view flags. Because `detectChangesInView` will immediately clear the `RefreshView` flag, this change is much more limited and does not result in a different set of flags during the view refresh. PR Close #53021
|
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. |
ChellappanRajan
pushed a commit
to ChellappanRajan/angular
that referenced
this pull request
Jan 23, 2024
… views (angular#53021) This change fixes and issue where the expectation was that change detection always goes through `detectChangesInView`. In reality, `detectChangesInternal` directly calls `refreshView` and refreshes a view directly without checking if it was dirty (to my discontent). This update changes the implementation of `detectChangesInternal` to actually be "detect changes" not "force refresh of root view and detect changes". In addition, it adds the refresh flag to APIs that were previously calling `detectChangesInternal` so we get the same behavior as before (host view is forced to refresh). Note that the use of `RefreshView` instead of `Dirty` is _intentional_ here. The `RefreshView` flag is cleared before refreshing the view while the `Dirty` flag is cleared at the very end. Using the `Dirty` flag could have consequences because it is a more long-lasting change to the view flags. Because `detectChangesInView` will immediately clear the `RefreshView` flag, this change is much more limited and does not result in a different set of flags during the view refresh. PR Close angular#53021
rlmestre
pushed a commit
to rlmestre/angular
that referenced
this pull request
Jan 26, 2024
… views (angular#53021) This change fixes and issue where the expectation was that change detection always goes through `detectChangesInView`. In reality, `detectChangesInternal` directly calls `refreshView` and refreshes a view directly without checking if it was dirty (to my discontent). This update changes the implementation of `detectChangesInternal` to actually be "detect changes" not "force refresh of root view and detect changes". In addition, it adds the refresh flag to APIs that were previously calling `detectChangesInternal` so we get the same behavior as before (host view is forced to refresh). Note that the use of `RefreshView` instead of `Dirty` is _intentional_ here. The `RefreshView` flag is cleared before refreshing the view while the `Dirty` flag is cleared at the very end. Using the `Dirty` flag could have consequences because it is a more long-lasting change to the view flags. Because `detectChangesInView` will immediately clear the `RefreshView` flag, this change is much more limited and does not result in a different set of flags during the view refresh. PR Close angular#53021
amilamen
pushed a commit
to amilamen/angular
that referenced
this pull request
Jan 26, 2024
… views (angular#53021) This change fixes and issue where the expectation was that change detection always goes through `detectChangesInView`. In reality, `detectChangesInternal` directly calls `refreshView` and refreshes a view directly without checking if it was dirty (to my discontent). This update changes the implementation of `detectChangesInternal` to actually be "detect changes" not "force refresh of root view and detect changes". In addition, it adds the refresh flag to APIs that were previously calling `detectChangesInternal` so we get the same behavior as before (host view is forced to refresh). Note that the use of `RefreshView` instead of `Dirty` is _intentional_ here. The `RefreshView` flag is cleared before refreshing the view while the `Dirty` flag is cleared at the very end. Using the `Dirty` flag could have consequences because it is a more long-lasting change to the view flags. Because `detectChangesInView` will immediately clear the `RefreshView` flag, this change is much more limited and does not result in a different set of flags during the view refresh. PR Close angular#53021
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
… views
This change fixes and issue where the expectation was that change detection always goes through
detectChangesInView. In reality,detectChangesInternaldirectly callsrefreshViewand refreshes a view directly without checking if it was dirty (to my discontent).This update clears the refresh flags at the top of
refreshViewas well as before traversing child views inTargetedmode. The issue only partially exists with signals in that the flags aren't cleared but we don't end up refreshing the view a second time because theconsumerPollProducersForChangereturnsfalsethe second time we enterdetectChangesInView.