This repository has been archived by the owner on Apr 12, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(ngAnimate): complete rewrite of animations
- ngAnimate directive is gone and was replaced with class based animations/transitions - support for triggering animations on css class additions and removals - done callback was added to all animation apis - $animation and $animator where merged into a single $animate service with api: - $animate.enter(element, parent, after, done); - $animate.leave(element, done); - $animate.move(element, parent, after, done); - $animate.addClass(element, className, done); - $animate.removeClass(element, className, done); BREAKING CHANGE: too many things changed, we'll write up a separate doc with migration instructions
- Loading branch information
Showing
40 changed files
with
2,961 additions
and
2,191 deletions.
There are no files selected for viewing
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,3 +8,7 @@ | |
ng\:form { | ||
display: block; | ||
} | ||
|
||
.ng-hide { | ||
display: none; | ||
} |
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
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
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
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
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
Oops, something went wrong.
81923f1
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.
Hello, while I like this approach (in theory), I have noticed that as a result of this change, just including
ngAnimate
in my mobile app is causing performance on mobile devices (iPad) to degrade in anng-repeat
of around 50 items. Basically the list takes a slight delay to appear (with a bit of a flicker), whereas before it would have appeared immediately. I am attributing this delay and performance hit to the DOM adding and removing the animation classes to and from all my list items individually. It's happening everywhere I have anng-repeat
defined (I have no animations defined in my CSS yet).My problem with this approach is that it's no longer optional... if you include
ngAnimate
you will have the adding and removal of class names all over the place. What if I just want to animateng-view
withoutng-repeat
? Why should the DOM be adding all of those classes to elements that didn't even need an animation in the first place? That's a lot of overhead for no gain. DOM manipulation is expensive and noticabely slower in mobile browsers, even an iPad 4gen running iOS 6.81923f1
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.
Hmm, maybe the be a solution could be to add a
.ng-animate-skip
className for cases like this.81923f1
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.
This sounds concerning. Could you provide us with a plunker which we could use to verify and debug this?
81923f1
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.
I have set up a very basic plunkr here: http://plnkr.co/edit/x7baZHgI93pRWYScQIHs
The flickering is even visible in chrome, when removing items from the list.
If you remove
ngAnimate
as a dependency you'll see how this performs much smoother.81923f1
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.
I encourage you to test this on apps in the wild (especially mobile ones) that have lots of
ngRepeat
to test it out...Another thing I've been wondering about this approach is that it used to be possible to pass a function to
ngAnimate
... likeng-animate="forwardOrBack()"
, and then programmatically choose the animation to apply based on the CSS classes that get added and removed. Now that the animations are just static css classes that automatically get added and removed, it doesn't seem possible to "choose" let's say, the direction of the animation (e.g. slide right or slide left depending on routing logic), other than targeting this with outer CSS classes.I think that the declarative nature of
ngAnimate
directive is preferable to me over this "catch-all" approach. But I'd love to hear more about why this change was made!81923f1
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.
We did think about how to do this and since ngAnimate is class-based you would use ngClass or an expression within a class attribute to toggle the classes on the element. When this changes, then the next animation will pay attention to the new CSS classes on the element. You can also use a function within the ngClass expression to return an object or string of classes. This all works, but there is a slight bug right now where ngRepeat, ngInclude or ngView doesn't pickup the ngClass changes before animating if the element is transcluded, but this will be shortly fixed (I also think that this relates to the issue you posted earlier).