Skip to content

Conversation

@thePunderWoman
Copy link
Contributor

@thePunderWoman thePunderWoman commented Sep 12, 2025

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

@thePunderWoman thePunderWoman added state: WIP area: core Issues related to the framework runtime labels Sep 12, 2025
@ngbot ngbot bot added this to the Backlog milestone Sep 12, 2025
@thePunderWoman thePunderWoman marked this pull request as draft September 12, 2025 21:53
@thePunderWoman thePunderWoman force-pushed the animation-content-projection branch 5 times, most recently from ee085e0 to d9a902a Compare September 24, 2025 23:06
@thePunderWoman thePunderWoman marked this pull request as ready for review September 24, 2025 23:20
@thePunderWoman thePunderWoman added target: patch This PR is targeted for the next patch release action: review The PR is still awaiting reviews from at least one requested reviewer and removed state: WIP labels Sep 24, 2025
@thePunderWoman thePunderWoman force-pushed the animation-content-projection branch 2 times, most recently from c127045 to 1729105 Compare September 25, 2025 19:55
@thePunderWoman thePunderWoman marked this pull request as draft September 25, 2025 23:21
@thePunderWoman thePunderWoman force-pushed the animation-content-projection branch 10 times, most recently from 01c3896 to 6966809 Compare September 26, 2025 21:31
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 thePunderWoman reopened this Oct 1, 2025
@thePunderWoman thePunderWoman added action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews and removed action: merge The PR is ready for merge by the caretaker labels Oct 1, 2025
@thePunderWoman thePunderWoman force-pushed the animation-content-projection branch from 4e81b89 to 92f8707 Compare October 1, 2025 23:32
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 thePunderWoman force-pushed the animation-content-projection branch from 92f8707 to 3f5a420 Compare October 1, 2025 23:43
@thePunderWoman thePunderWoman added the action: global presubmit The PR is in need of a google3 global presubmit label Oct 2, 2025
@thePunderWoman
Copy link
Contributor Author

TGP

@thePunderWoman thePunderWoman added action: merge The PR is ready for merge by the caretaker merge: caretaker note Alert the caretaker performing the merge to check the PR for an out of normal action needed or note and removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews action: global presubmit The PR is in need of a google3 global presubmit labels Oct 2, 2025
@thePunderWoman
Copy link
Contributor Author

thePunderWoman commented Oct 2, 2025

Caretaker note: the TGP is green. This is safe to merge.

@mmalerba
Copy link
Contributor

mmalerba commented Oct 2, 2025

This PR was merged into the repository. The changes were merged into the following branches:

@mmalerba mmalerba closed this in dd7c4cd Oct 2, 2025
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
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
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
@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 Nov 2, 2025
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

Projects

None yet

4 participants