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

AnimationPlayer onStart and onDone events emit only once #26630

Closed
MurhafSousli opened this issue Oct 21, 2018 · 4 comments
Closed

AnimationPlayer onStart and onDone events emit only once #26630

MurhafSousli opened this issue Oct 21, 2018 · 4 comments
Labels
area: animations freq3: high P4 A relatively minor issue that is not relevant to core functions type: bug/fix
Milestone

Comments

@MurhafSousli
Copy link

MurhafSousli commented Oct 21, 2018

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

AnimationPlayer onStart and onDone events emit only once, a new player has to be created to get the events to work again

Expected behavior

AnimationPlayer onStart and onDone events should work again after the first play

Minimal reproduction of the problem with instructions

  this.animationBuilder.build([
      query(
        '.child-element',
        [
          stagger(100, [useAnimation(animation)])
        ]
      )
    ]);
    this.player = builder.create(this.el.nativeElement);
    this.player.onStart(() => {
      console.log('animation onStart');
    });
    this.player.onDone(() => {
      console.log('animation onDone');
    });

https://stackblitz.com/edit/angular-bynhgg?file=src/app/app.component.ts

What is the motivation / use case for changing the behavior?

Be able to reuse the player

Environment


Angular version: 7.0.0


Browser:
- [x ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: 8  
- Platform:  Windows

Others:

Could be related to #26095

@crushjz
Copy link

crushjz commented Jun 24, 2019

This is really annoying, as it defeats the reusability purpose of the AnimationPlayer.

Angular 8.0 issue reproduced here: https://stackblitz.com/edit/angular-na3vhi

@jelbourn jelbourn added P4 A relatively minor issue that is not relevant to core functions and removed severity2: inconvenient labels Oct 1, 2020
@peternixey
Copy link

I've discovered that you can make the same player emit again but you need to register the callback for every single play.

this.releasedOver$.subscribe(() => {
  this.animation.play()
  this.animation.onDone(() => this.animation?.reset())
})

I'm rolling with this as a solution for the time being but if and when you solve this problem it would be great if it ships with a deprecation warning so that I (/we) don't end up with memory leaks. Thank you!

dario-piotrowicz added a commit to dario-piotrowicz/angular that referenced this issue Jun 14, 2022
in the animation players, don't delete the _onStartFns and _onDoneFns
after they have been called so that they can be called again after
resetting the animation

also set the _finished to false when the animation player starts
(so that the done functions can also be re-triggered)

resolves angular#26630
@dario-piotrowicz
Copy link
Contributor

Hello, I have opened an attempt to fix this issue, what I came up with was allowing the callbacks to be called after the animation gets reset

So for example this is the current behavior:
before

Which I updated to this:
after

I could have changed things so that the callbacks would be always called without the need to reset the animation, but that would basically auto-reset the animation after it has completed, which I'd imagine we don't want (and would make the reset function almost noop).

So I think/hope this makes sense and hopefully it can help with the situations described in this thread 🙂 , please let me know what you think 🙏

dario-piotrowicz added a commit to dario-piotrowicz/angular that referenced this issue Jun 15, 2022
in the animation players, make sure than upon reset the
_onStartFns and _onDoneFns are also re-applied so that
they can be called again after resetting the animation

also set the noop animation player's _finished to false
when the player resets (needed to make sure that the _onDoneFns
get called)

resolves angular#26630
dario-piotrowicz added a commit to dario-piotrowicz/angular that referenced this issue Jun 19, 2022
in the animation players, make sure than upon reset the
_onStartFns and _onDoneFns are also re-applied so that
they can be called again after resetting the animation

also set the noop animation player's _finished to false
when the player resets (needed to make sure that the _onDoneFns
get called)

resolves angular#26630
AndrewKushnir pushed a commit that referenced this issue Jun 21, 2022
in the animation players, make sure than upon reset the
_onStartFns and _onDoneFns are also re-applied so that
they can be called again after resetting the animation

also set the noop animation player's _finished to false
when the player resets (needed to make sure that the _onDoneFns
get called)

resolves #26630

PR Close #46364
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jul 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: animations freq3: high P4 A relatively minor issue that is not relevant to core functions type: bug/fix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants