fix(core): Fixes animations in conjunction with content projection - #63776
Closed
thePunderWoman wants to merge 1 commit into
Closed
thePunderWoman wants to merge 1 commit into
thePunderWoman wants to merge 1 commit into
Conversation
thePunderWoman
marked this pull request as draft
September 12, 2025 21:53
thePunderWoman
force-pushed
the
animation-content-projection
branch
5 times, most recently
from
September 24, 2025 23:06
ee085e0 to
d9a902a
Compare
thePunderWoman
marked this pull request as ready for review
September 24, 2025 23:20
thePunderWoman
commented
Sep 24, 2025
thePunderWoman
commented
Sep 24, 2025
thePunderWoman
force-pushed
the
animation-content-projection
branch
2 times, most recently
from
September 25, 2025 19:55
c127045 to
1729105
Compare
thePunderWoman
commented
Sep 25, 2025
thePunderWoman
marked this pull request as draft
September 25, 2025 23:21
thePunderWoman
force-pushed
the
animation-content-projection
branch
10 times, most recently
from
September 26, 2025 21:31
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
thePunderWoman
force-pushed
the
animation-content-projection
branch
from
October 1, 2025 23:32
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
thePunderWoman
force-pushed
the
animation-content-projection
branch
from
October 1, 2025 23:43
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. |
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.
4 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.
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