getndazn / kopytko-utils

A collection of modern utility functions for Brightscript applications
MIT License
6 stars 4 forks source link

fix: [ROKU-1647] Animation does not work when called in the callback #20

Closed bchelkowski closed 1 year ago

bchelkowski commented 1 year ago

What did you implement:

Closes https://github.com/getndazn/kopytko-utils/issues/19

The behavior of the animate function should now be handled properly and it should be possible to call new animations when the previous one was resolved or rejected.

However, I don't fully understand why aborted animation is rejected and handled like an error, but I didn't change this behavior to not break anything in case of someone already handling it this way and to not introduce a breaking change.

How did you implement it:

AnimatorCore.animate before clearing up the previous animation context checks if the previous promise was resolved. If yes, then it queues the next animation instead of replacing the old one.

How can we verify it:

Given there is a component with an id container the following code:

    m.container.opacity = 1.0

    ' Immediate calls
    Animator().fadeOut(m.container, { duration: 2 }).finally(sub (state as String)
      ?"Faded Out - ";state
    end sub)
    Animator().fadeIn(m.container, { duration: 2 }).finally(sub (state as String)
      ?"Faded In - ";state
    end sub)
    Animator().fadeOut(m.container, { duration: 2 }).finally(sub (state as String, m as Object)
      ?"Again Faded Out - ";state
      ' Callback calls
      Animator().fadeIn(m.container, { duration: 2 }).finally(sub (state as String, m as Object)
        ?"Again Faded In - ";state
        Animator().fadeOut(m.container, { duration: 2 }).finally(sub (state as String, m as Object)
          ?"And Again Faded Out - ";state
          Animator().fadeIn(m.container, { duration: 2 }).finally(sub (state as String)
            ?"And Again Faded In - ";state
          end sub)
        end sub, m)
      end sub, m)
    end sub, m)

should log the following steps:

Faded Out - aborted
Faded In - aborted
Again Faded Out - stopped
Again Faded In - stopped
And Again Faded Out - stopped
And Again Faded In - stopped

And all animations should behave accordingly, so 2 first will be aborted, and the next 4 should proceed in proper order.

Todos:

Is this ready for review?: YES Is it a breaking change?: NO

github-actions[bot] commented 1 year ago

:tada: This PR is included in version 2.3.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket: