You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Do you want to request a feature or report a bug?
It's a feature (it would be a bug but appears to be a known issue in the source).
What is the current behavior?
Calling animateProvider.classNameFilter can register a class name filter at configuration time. However, it can't be called after the the animation service has actually been "$get"-ed and still work, there seems to be some optimization work being done at construction time which stores the value for later use.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).
What is the expected behavior?
I want to be able to register a different class name filter at run time. This will have the net effect of letting me 'disable' ng-animate by specifying an unmatched filter at config time, and enable it if I have flighted the animation feature into our running client. I could instead use a broader "disableAnimations"/"enableAnimations" semantic to address the issue, if that would be preferred.
What is the motivation / use case for changing the behavior?
To enable more diverse use cases. In my org, we want to fully test and flight animations before enabling them broadly for all production users.
Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
We're using Angular 1.5.x.
Other information (e.g. stacktraces, related issues, suggestions how to fix)
The text was updated successfully, but these errors were encountered:
The usecase of globally enabling/disabling animations is already covered with $animate.enabled(true/false). With #14914 you will be able to have more fine-grained control, e.g. enabling/disabling animations on specific parts of the page.
Closing since this is working as intended and the requested usecase is already supported.
Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.
Do you want to request a feature or report a bug?
It's a feature (it would be a bug but appears to be a known issue in the source).
What is the current behavior?
Calling animateProvider.classNameFilter can register a class name filter at configuration time. However, it can't be called after the the animation service has actually been "$get"-ed and still work, there seems to be some optimization work being done at construction time which stores the value for later use.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).
What is the expected behavior?
I want to be able to register a different class name filter at run time. This will have the net effect of letting me 'disable' ng-animate by specifying an unmatched filter at config time, and enable it if I have flighted the animation feature into our running client. I could instead use a broader "disableAnimations"/"enableAnimations" semantic to address the issue, if that would be preferred.
What is the motivation / use case for changing the behavior?
To enable more diverse use cases. In my org, we want to fully test and flight animations before enabling them broadly for all production users.
Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
We're using Angular 1.5.x.
Other information (e.g. stacktraces, related issues, suggestions how to fix)
The text was updated successfully, but these errors were encountered: