Open mattbrailsford opened 2 months ago
Hey @mattbrailsford — been a while since I worked on this, but IIRC the main reason for not doing this was to avoid the risk that things get stuck because a done()
method was never called. It also helps keeps things centralised for cases where there are multiple animations. I agree though that I was never super happy about how bgio-effects
forced moving front-end concerns such as animation duration into the effect definitions.
No worries, and I appreciate the feedback.
That did cross my mind too, but I guess there is a risk either way right? There is a possibility that something doesn't call done()
but with the existing timeline feature there is a risk that actual animations don't align with the timed notifications, so you might still end up in a situation where the move is revealed before the animation is complete.
Ultimately I think I just share the same thought that it would be nice for bgio-effects
to not be concerned with the animations and leave that for the implementor.
I may have a play around, but thanks for the input. It's good to know it was considered and your reasons for going a different way 👍
At the moment if you want to trigger some kind of animation, we have to configure a duration for that animation and then we receive a notification when that duration lapses.
Would it make sense to allow an initial effect handler to be passed a ‘done()’ delegate that can be fired after an animation is finished to allow the animation to control when the state update occurs?