This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Synchronous Classes in ngAnimate #12248
Closed
Conversation
This file contains 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
|
reviewed with Matsko. once all tests and demos are passing then this LGTM |
matsko
force-pushed
the
ng_animate_sync_classes
branch
4 times, most recently
from
d71c460 to
46f22ab
Compare
|
@petebacondarwin could you please review? |
matsko
force-pushed
the
ng_animate_sync_classes
branch
from
46f22ab to
b16d747
Compare
…e transition-delay styling
…skipPreparationClasses is present
…ed out with a RAF
matsko
force-pushed
the
ng_animate_sync_classes
branch
from
b16d747 to
d50894d
Compare
…losed by their children This fix ensures that a structural child animation will never close a parent class based early so that the CSS classes for the child are ready for it to perform its CSS animation. The reasoning for the past for this was because their is a one frame delay before the classes were applied. If a parent and a child animation happen at the same time then the animations may not be picked up for the element since the CSS classes may not have been applied yet. This fix ensures that parent CSS classes are applied in a synchronous manner without the need to run a one RAF wait. The solution to this was to apply the preparation classes during the pre-digest phase and then apply the CSS classes right after with a forced reflow paint. BREAKING CHANGE: CSS classes added/removed by ngAnimate are now applied synchronously once the first digest has passed. The previous behavior involved ngAnimate having to wait for one requestAnimationFrame before CSS classes were added/removed. The CSS classes are now applied directly after the first digest that is triggered after `$animate.addClass`, `$animate.removeClass` or `$animate.setClass` is called. If any of your code relies on waiting for one frame before checking for CSS classes on the element then please change this behavior. If a parent class-based animation, however, is run through a JavaScript animation which triggers an animation for `beforeAddClass` and/or `beforeRemoveClass` then the CSS classes will not be applied in time for the children (and the parent class-based animation will not be cancelled by any child animations). Closes angular#11975 Closes angular#12276
matsko
force-pushed
the
ng_animate_sync_classes
branch
from
d50894d to
04ca859
Compare
|
Landed as 32d3cbb |
|
Great! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This PR ensures that classes added via $animate are always applied after the first digest instead of after the first requestAnimationFrame.
Closes #11975
Closes #12276