Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/resolve evenbetter #762

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

gillyspy
Copy link

the promise behind an animation is a bit awkward to use. It is a deferred pattern that the anime controls internally and recreates. There are 2 situations that are problematic:

Situation A

because the resolve does not return the instance i find that i am regularly assigning a variable to the animation and then referring to that in promises. This is a bit awkward, especially for combined promises (like race, etc)

Promise.race( [anime({targets : X}), anime({targets:Y})] )
   .then(()=>UmWhoWon())

after this PR

Promise.race( [anime({targets : X}), anime({targets:Y})] )
   .then(winner=> chickenDinner(winner) )

Situation B

An instance that is not in a timeline will never really resolve if there is no timeline attached but the animation is removed.
This is because there is an internal pause that user-code cannot know about;
e.g.:

const a = anime({ targets : X});  
a.finished.then(a=>ohShitImBored() ); 
a.remove('*'); // this will remove all (selector based) targets and imply a pause

after this PR

const ImTheBossOfMe = function(a){
   //some stuff
   a.play();
}
const a = anime({ targets : X, onPause: ImTheBossOfMe });  
a.finished.then(a=>definitelyGettingHereNow() ); 
a.remove('*'); // this will remove all (selector based) targets and imply a pause...BUT WHO CARES NOW 😄 

…ide way to deal with anime internal pause (that user code does not control or know about otherwise). Add promise state monitoring via property : finishedState
@gillyspy
Copy link
Author

@juliangarnier are you still actively developing?

in case you are wondering this feature does not really change any of the current behaviour but makes promises a more reasonable use-case here.

@juliangarnier
Copy link
Owner

Nice!

Yes I am, v3.3.0 is coming along nicely, but there are still a lot to do.

Can you rebase this PR on the v3.3.0 branch ?
I'm adding tests to 3.3, it would be nice if you can update tests/promises.test.js to reflect the changes of this PR.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants