-
Notifications
You must be signed in to change notification settings - Fork 26.9k
fix(core): Fixes animations in conjunction with content projection #63776
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
thePunderWoman
wants to merge
1
commit into
angular:main
from
thePunderWoman:animation-content-projection
Closed
fix(core): Fixes animations in conjunction with content projection #63776
thePunderWoman
wants to merge
1
commit into
angular:main
from
thePunderWoman:animation-content-projection
Conversation
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
ee085e0 to
d9a902a
Compare
thePunderWoman
commented
Sep 24, 2025
thePunderWoman
commented
Sep 24, 2025
c127045 to
1729105
Compare
thePunderWoman
commented
Sep 25, 2025
01c3896 to
6966809
Compare
mmalerba
pushed a commit
that referenced
this pull request
Oct 1, 2025
mmalerba
pushed a commit
that referenced
this pull request
Oct 1, 2025
4e81b89 to
92f8707
Compare
Content Projected nodes are not destroyed and recreated, like every other situation. Enter and Leave animations were ephemeral and are expected to run once, and then be cleared. This means that for content projection cases, the animations would only ever work the first time they were shown / hid. In order to resolve this, we move to an animation queue that re-runs the animation functions stored in the LView. In most cases, this animation will run once on creation. For content projection, the enter and leave animations will fire more than once. Animations are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated. So we only run animations for an affected RNode, rather than potentially all in the LView. This also moves the queue to afterRender, which is safer than right after template execution in refreshView. fixes: angular#63418 fixes: angular#64065 fixes: angular#63901
92f8707 to
3f5a420
Compare
Contributor
Author
Contributor
Author
|
Caretaker note: the TGP is green. This is safe to merge. |
Contributor
mmalerba
pushed a commit
that referenced
this pull request
Oct 2, 2025
…63776) Content Projected nodes are not destroyed and recreated, like every other situation. Enter and Leave animations were ephemeral and are expected to run once, and then be cleared. This means that for content projection cases, the animations would only ever work the first time they were shown / hid. In order to resolve this, we move to an animation queue that re-runs the animation functions stored in the LView. In most cases, this animation will run once on creation. For content projection, the enter and leave animations will fire more than once. Animations are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated. So we only run animations for an affected RNode, rather than potentially all in the LView. This also moves the queue to afterRender, which is safer than right after template execution in refreshView. fixes: #63418 fixes: #64065 fixes: #63901 PR Close #63776
napulitanfrontend
pushed a commit
to napulitanfrontend/angular
that referenced
this pull request
Oct 10, 2025
…ngular#63776) Content Projected nodes are not destroyed and recreated, like every other situation. Enter and Leave animations were ephemeral and are expected to run once, and then be cleared. This means that for content projection cases, the animations would only ever work the first time they were shown / hid. In order to resolve this, we move to an animation queue that re-runs the animation functions stored in the LView. In most cases, this animation will run once on creation. For content projection, the enter and leave animations will fire more than once. Animations are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated. So we only run animations for an affected RNode, rather than potentially all in the LView. This also moves the queue to afterRender, which is safer than right after template execution in refreshView. fixes: angular#63418 fixes: angular#64065 fixes: angular#63901 PR Close angular#63776
napulitanfrontend
pushed a commit
to napulitanfrontend/angular
that referenced
this pull request
Oct 10, 2025
…ction (angular#63776)" (angular#64189) This reverts commit 1cb16fd. PR Close angular#64189
napulitanfrontend
pushed a commit
to napulitanfrontend/angular
that referenced
this pull request
Oct 10, 2025
…ngular#63776) Content Projected nodes are not destroyed and recreated, like every other situation. Enter and Leave animations were ephemeral and are expected to run once, and then be cleared. This means that for content projection cases, the animations would only ever work the first time they were shown / hid. In order to resolve this, we move to an animation queue that re-runs the animation functions stored in the LView. In most cases, this animation will run once on creation. For content projection, the enter and leave animations will fire more than once. Animations are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated. So we only run animations for an affected RNode, rather than potentially all in the LView. This also moves the queue to afterRender, which is safer than right after template execution in refreshView. fixes: angular#63418 fixes: angular#64065 fixes: angular#63901 PR Close angular#63776
napulitanfrontend
pushed a commit
to napulitanfrontend/angular
that referenced
this pull request
Oct 11, 2025
…ngular#63776) Content Projected nodes are not destroyed and recreated, like every other situation. Enter and Leave animations were ephemeral and are expected to run once, and then be cleared. This means that for content projection cases, the animations would only ever work the first time they were shown / hid. In order to resolve this, we move to an animation queue that re-runs the animation functions stored in the LView. In most cases, this animation will run once on creation. For content projection, the enter and leave animations will fire more than once. Animations are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated. So we only run animations for an affected RNode, rather than potentially all in the LView. This also moves the queue to afterRender, which is safer than right after template execution in refreshView. fixes: angular#63418 fixes: angular#64065 fixes: angular#63901 PR Close angular#63776
napulitanfrontend
pushed a commit
to napulitanfrontend/angular
that referenced
this pull request
Oct 11, 2025
…ction (angular#63776)" (angular#64189) This reverts commit 1cb16fd. PR Close angular#64189
napulitanfrontend
pushed a commit
to napulitanfrontend/angular
that referenced
this pull request
Oct 11, 2025
…ngular#63776) Content Projected nodes are not destroyed and recreated, like every other situation. Enter and Leave animations were ephemeral and are expected to run once, and then be cleared. This means that for content projection cases, the animations would only ever work the first time they were shown / hid. In order to resolve this, we move to an animation queue that re-runs the animation functions stored in the LView. In most cases, this animation will run once on creation. For content projection, the enter and leave animations will fire more than once. Animations are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated. So we only run animations for an affected RNode, rather than potentially all in the LView. This also moves the queue to afterRender, which is safer than right after template execution in refreshView. fixes: angular#63418 fixes: angular#64065 fixes: angular#63901 PR Close angular#63776
|
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.
Labels
action: merge
The PR is ready for merge by the caretaker
area: core
Issues related to the framework runtime
merge: caretaker note
Alert the caretaker performing the merge to check the PR for an out of normal action needed or note
target: patch
This PR is targeted for the next patch release
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.
Content Projected nodes are not destroyed and recreated, like every other
situation. Enter and Leave animations were ephemeral and are
expected to run once, and then be cleared. This means that for content projection
cases, the animations would only ever work the first time they were shown / hid.
In order to resolve this, we move to an animation queue that re-runs the animation
functions stored in the LView. In most cases, this animation will run once on creation.
For content projection, the enter and leave animations will fire more than once. Animations
are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated.
So we only run animations for an affected RNode, rather than potentially all in the LView.
This also moves the queue to afterRender, which is safer than right after template
execution in refreshView.
fixes: #63418
fixes: #64065
fixes: #63901