Open Boscop opened 1 year ago
As you've correctly described that both approaches are very different, I don't think it makes sense to expose them under the same API. Introducing an API that is only helpful when the user is deciding which function to use doesn't sound right to me
Summary
Both
Interval
andrequest_animation_frame
can be used to schedule callbacks that get called in regular intervals, but they both have a very different API. This proposal unifies their APIs with one trait (FrameScheduler
).Motivation
A user might want to try different approaches for running a callback in regular intervals, and a unified API would make it easier. In many use cases (when it's not an animation) the decision is not clear cut, because both approaches have different properties (
setInterval
has jitter but allows calling in faster intervals thanrequestAnimationFrame
) and the user might want to test both for their use case. E.g. in my use case I was implementing a midi player and it needs to be stepped forward in regular intervals.Detailed Explanation
It's quite self-explanatory:
Unresolved Questions
It would be nice to get the
Context
instance back when the "loop" terminates. If the loop terminates because of the callback returning false, the context could be preserved by storing it in theRc
. But if it's terminated via callingstop
, the context can't be recovered because it gets dropped along with the closure that captured it. Maybe someone has an idea for how to do it though..