10000 $CoreAnimateCssProvider runner.done() behavior doesn't match animateCss docs · Issue #13205 · angular/angular.js · GitHub
[go: up one dir, main page]

Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
$CoreAnimateCssProvider runner.done() behavior doesn't match animateCss docs #13205
Closed
@mikyladewitt

Description

@mikyladewitt

The $CoreAnimateCssProvider's implementation of the runner.done() function behavior doesn't match the behavior that is documented in the ngAnimate.$animateCss documentation.

The ngAnimate.$animateCss documentation says:

runner.done() vs runner.then()

It is documented that animation.start() will return a promise object and this is true, however, there is also an additional method available on the runner called .done(callbackFn). The done method works the same as .finally(callbackFn), however, it does not trigger a digest to occur. Therefore, for performance reasons, it's always best to use runner.done(callback) instead of runner.then(), runner.catch() or runner.finally() unless you really need a digest to kick off afterwards.

The $CoreAnimateCssProvider'srunner.done() implemenation takes the first argument as a flag indicating if the promise should be canceled or not. The callback passed in will never be called:

    done: function(cancel) {
        this.defer && this.defer[cancel === true ? 'reject' : 'resolve']();
    },

Because the $CoreAnimateCssProvider links to the ngAnimate.$animateCss documentation, I would expect the $CoreAnimateCssProvider to behave the same way.

This is causing bugs for other projects that that allow users to opt-in to animations and depend on the done() method.

< 48DA /div>

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0