feat($animate): add support for customFilter#14914
Conversation
4eb6dba to
2021884
Compare
| $animateProvider.customFilter(angular.noop); | ||
| expect($animateProvider.customFilter()).toEqual(jasmine.any(Function)); | ||
|
|
||
| $animateProvider.customFilter({}); |
There was a problem hiding this comment.
perhaps we should throw instead of silently ignoring?
There was a problem hiding this comment.
I kept this consistent with classNameFilter (although it is preferrable to throw obviously).
Throwing would be a BC for classNameFilter. Should I fix this one to throw and make classNameFilter throw for 1.6 (or leave it as is)?
There was a problem hiding this comment.
I would change both as you suggest.
There was a problem hiding this comment.
I missed that this needed to land in 1.6.0 (due to the BC) 😞
I will make only customFilter throw for 1.6.x/1.7.x and change classNameFilter to also throw for 1.7.x only.
There was a problem hiding this comment.
Actually, I just realized that the current implementation allows to "clear" the filter/className by passing a non-Function/non-RegExp argument. So, if we want to throw, we need to still allow some special value (e.g. null/undefined/falsy?) for unsetting the filter/className.
|
One minor question - otherwise LGTM |
|
I like it. I would add a note though that this going to be called for every animatable action, so developers should keep the function lean. |
2021884 to
435f690
Compare
435f690 to
6b70025
Compare
|
I added docs for Feel free to TAL |
|
|
||
| /** | ||
| * @ngdoc method | ||
| * @name $animateProvider#customFilter |
There was a problem hiding this comment.
I would add two things:
- How does this relate to the classFilter, .i.e. what takes precedence, or do both run
- Note that this runs for every
animatableaction, not just for animations that are actually defined, and that the user should keep the function fast
You've added this to the guide, but I think it should be here too
There was a problem hiding this comment.
How does this relate to the classFilter, .i.e. what takes precedence, or do both run
👍
Note that this runs for every animatable action, not just for animations that are actually defined, and that the user should keep the function fast
You mean in addition to the alert-box below?
There was a problem hiding this comment.
If possible, I thought we should make it explicit (in the alert box) that this doesn't only affect the actual animations, but every "action" (class change, element entering). I think this difference is easily forgotten, and people might think "Oh well I don't have many animations anyway".
There was a problem hiding this comment.
I see what you mean now. Good point. I will update the API docs and guide.
BTW, I think we should re-order the conditions, because now customFilter and classNameFilter are executed even if animations are globally disabled or the document is hidden etc.
| triggered, will attempt to perform a CSS Transition, CSS Keyframe Animation or a JavaScript callback Animation (depending on if an animation is | ||
| placed on the given directive). Animations can be placed using vanilla CSS by following the naming conventions set in place by AngularJS | ||
| or with JavaScript code when it's defined as a factory. | ||
| AngularJS provides animation hooks for common directives such as `ngRepeat`, `ngSwitch`, and |
There was a problem hiding this comment.
While you are at it, can you add links to the directives here?
| This ensures that the whole app has been compiled fully before animations are attempted. | ||
| Internally, `ngAnimate` waits until all template downloads that are started right after bootstrap | ||
| have finished. Then, it waits for the currently running {@link ng.$rootScope.Scope#$digest $digest} | ||
| and the one more after that to finish. This ensures that the whole app has been compiled fully |
There was a problem hiding this comment.
"and one more after that, to finish."
|
|
||
| When the first argument is a native DOM or jqLite/jQuery element, the function enables / disables | ||
| animations on this element *and all its children*: `$animate.enabled(myElement, false)`. This is the | ||
| most flexible way to change the animation state. For example, even if you have used it to disable |
There was a problem hiding this comment.
Is "This is the most flexible way to change the animation state." still true with the new customFilter? I don't think so, as $animate.enabled() does not work when the classNameFilter or customFilter are active. So let's remove this sentence
|
|
||
|
|
||
| ### Enable animations for elements outside of the Angular application DOM tree: {@link ng.$animate#pin $animate.pin()} | ||
| ### Enable animations outside of the application DOM tree: {@link ng.$animate#pin $animate.pin()} |
|
Comments addressed. PTAL |
3a78cf7 to
8c7a7b8
Compare
|
|
||
| /** | ||
| * @ngdoc method | ||
| * @name $animateProvider#customFilter |
There was a problem hiding this comment.
If possible, I thought we should make it explicit (in the alert box) that this doesn't only affect the actual animations, but every "action" (class change, element entering). I think this difference is easily forgotten, and people might think "Oh well I don't have many animations anyway".
|
Note to self: Update links after #15654. |
|
This looks (almost) done, wanna put it into 1.6.5? |
|
@gkalpak Looks like this needs a rebase. After that, I will do another review - or do you have some other changes to make? |
…mprovements) - List missing animation-aware directives. - Fix/Improve wording/formatting. - Fix typos. - Limit lines to 100 chars.
This commit adds a new `customFilter()` function on `$animateProvider` (similar to `classNameFilter()`), which can be used to filter animations (i.e. decide whether they are allowed or not), based on the return value of a custom filter function. This allows to easily create arbitrarily complex rules for filtering animations, such as allowing specific events only, or enabling animations on specific subtrees of the DOM, etc. Fixes angular#14891
8c7a7b8 to
7e6660c
Compare
7e6660c to
237874b
Compare
|
I have squashed and rebased this and added two new commits:
@Narretz PTAL |
Narretz
left a comment
There was a problem hiding this comment.
Just two smaller docs changes needed, otherwise LGTM
| With these generated CSS class names present on the element at the time, AngularJS automatically | ||
| figures out whether to perform a CSS and/or JavaScript animation. If both CSS and JavaScript animation | ||
| code is present, and match the CSS class name on the element, then AngularJS will run both animations at the same time. | ||
| figures out whether to perform a CSS and/or JavaScript animation. If both CSS and JavaScript |
There was a problem hiding this comment.
That actually hasn't been true since 1.4 😱 https://code.angularjs.org/snapshot/docs/guide/migration#animation-nganimate-
There was a problem hiding this comment.
So, what happens if both are detected. Who wins?
There was a problem hiding this comment.
JS animations - because you can run CSS in JS: http://plnkr.co/edit/rdRAZTiXHNAFTEOHyZVo?p=preview
Although I'm surprised this isn't explicitly said in the migrate docs. But it is here: https://code.angularjs.org/snapshot/docs/api/ngAnimate
Unfortuante spreading out of content ... moving this in guide would be a good passion project for rainy afternoons. :p
There was a problem hiding this comment.
Changed and added a link to that api/ngAnimate section.
There is indeed useful info there that would be better in the guide 😞
| AngularJS also pays attention to CSS class changes on elements by triggering the **add** and | ||
| **remove** hooks. This means that if a CSS class is added to or removed from an element then an | ||
| animation can be executed in between, before the CSS class addition or removal is finalized. | ||
| (Keep in mind that AngularJS will only be able to capture class changes if an **expression** or the |
There was a problem hiding this comment.
I think interpolated expression is clearer here
…other improvements)
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature.
What is the new behavior (if this is a feature change)?
This commit adds a new
customFilter()function on$animateProvider(similar toclassNameFilter()), which can be used to filter animations (i.e. decide whether they are allowed or not), based on the return value of a custom filter function.This allows to easily create arbitrarily complex rules for filtering animations, such as allowing specific events only, or enabling animations on specific subtrees of the DOM etc.
Does this PR introduce a breaking change?
No.
Please check if the PR fulfills these requirements
Other information:
Fixes #14891.
Needs docs: