-
Notifications
You must be signed in to change notification settings - Fork 26.6k
fix(core): animation sometimes renderer not being destroyed during HMR #59574
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
Conversation
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.
There was a problem hiding this 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.
This PR was merged into the repository by commit b76be83. The changes were merged into the following branches: main, 19.1.x |
#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
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
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. |
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: