Skip to content

Conversation

crisbeto
Copy link
Member

These changes aim to resolve the issue that prompted #59514. The animations module is a bit tricky for HMR, because it schedules the destruction of its renderer after the currently-running animations are done. If there are no running animations, the renderer gets destroyed next time around. This is a problem, because it means that the styles can stay around for a long time.

These changes resolve the issue by:

  1. Moving the cleanup of the renderer to after the destruction of the old view. This ensures that the usual clean up flow has been kicked off.
  2. Flushing the animations when a component is replaced to ensure that the renderer is cleaned up in a timely manner.

These changes aim to resolve the issue that prompted angular#59514. The animations module is a bit tricky for HMR, because it schedules the destruction of its renderer after the currently-running animations are done. If there are no running animations, the renderer gets destroyed next time around. This is a problem, because it means that the styles can stay around for a long time.

These changes resolve the issue by:
1. Moving the cleanup of the renderer to after the destruction of the old view. This ensures that the usual clean up flow has been kicked off.
2. Flushing the animations when a component is replaced to ensure that the renderer is cleaned up in a timely manner.
@crisbeto crisbeto added action: review The PR is still awaiting reviews from at least one requested reviewer target: patch This PR is targeted for the next patch release labels Jan 16, 2025
@angular-robot angular-robot bot added the area: core Issues related to the framework runtime label Jan 16, 2025
@ngbot ngbot bot added this to the Backlog milestone Jan 16, 2025
Copy link
Contributor

@AndrewKushnir AndrewKushnir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks great 👍 If we can also add a test to capture this behavior to prevent regressions in the future - that'd be awesome.

@AndrewKushnir AndrewKushnir removed the request for review from clydin January 16, 2025 18:54
@AndrewKushnir AndrewKushnir removed the action: review The PR is still awaiting reviews from at least one requested reviewer label Jan 16, 2025
@crisbeto crisbeto added the action: merge The PR is ready for merge by the caretaker label Jan 16, 2025
@AndrewKushnir
Copy link
Contributor

This PR was merged into the repository by commit b76be83.

The changes were merged into the following branches: main, 19.1.x

AndrewKushnir pushed a commit that referenced this pull request Jan 16, 2025
#59574)

These changes aim to resolve the issue that prompted #59514. The animations module is a bit tricky for HMR, because it schedules the destruction of its renderer after the currently-running animations are done. If there are no running animations, the renderer gets destroyed next time around. This is a problem, because it means that the styles can stay around for a long time.

These changes resolve the issue by:
1. Moving the cleanup of the renderer to after the destruction of the old view. This ensures that the usual clean up flow has been kicked off.
2. Flushing the animations when a component is replaced to ensure that the renderer is cleaned up in a timely manner.

PR Close #59574
PrajaktaB27 pushed a commit to PrajaktaB27/angular that referenced this pull request Feb 7, 2025
angular#59574)

These changes aim to resolve the issue that prompted angular#59514. The animations module is a bit tricky for HMR, because it schedules the destruction of its renderer after the currently-running animations are done. If there are no running animations, the renderer gets destroyed next time around. This is a problem, because it means that the styles can stay around for a long time.

These changes resolve the issue by:
1. Moving the cleanup of the renderer to after the destruction of the old view. This ensures that the usual clean up flow has been kicked off.
2. Flushing the animations when a component is replaced to ensure that the renderer is cleaned up in a timely manner.

PR Close angular#59574
@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 Feb 16, 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 target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants