Proposal: Adding a way to handle a single and global frameloop with raf (requestAnimationFrame) related primitives?

[royeden]

Right now, the raf primitives don't allow a way to schedule multiple requests on the same animation frame (as multiple requests on animation frames can be scheduled for different frames and don't always guarantee scheduling at the same time).

The proposal would be to add a simple way to handle a frameloop, where you can schedule callbacks that run in a guaranteed batch.

This could be achieved (and is achievable now in userland) by:

• Creating a way to store the main animation frame (in my userland case, I used a context).
• Creating a way to store multiple framecallbacks (in my userland case, I used a Map<string, FrameCallback>).
• Creating an interface to handle the storage of these framecallbacks, for example a .set and .delete methods. Some other nice to haves could be provided with this interface, like an option to automatically run whenever there's at least a single framecallback stored and stopped when no callbacks are there.

An alternative to this would be providing the schedule / cancel logic so an external frameloop can be used with this primitive (I think if that's the chosen path, a good rule of thumb would be separating it into another primitive that's more specific for that use case).

These considerations come from motion's frame util or articles like this one (probably don't need to add the whole thing to the library, just a way to encourage the single frameloop practice instead of multiple scattered requestAnimationFrame calls).

[atk]

That's an interesting idea. We're open for PRs, if you want to provide such a primitive.

[royeden]

I'll try my hand at it then and see what I can come up with!

[thetarnav]

So if I understand correctly.
Instead of scheduling separate animation frames for each createAnimationFrame, it's better for performance to reuse a single one?
Sounds good.
Something simple like useAnimationFrame(callback) that automatically manages callbacks through reactive lifecycle.
It's not an uncommon idea in solid-primitives.
There are few primitives that use a "singleton root" to offer variants that reuse existing objects.
For example createWindowSize and useWindowSize.
There are probably other, fancier examples, but I need to look for them.

[royeden]

I think it would be nice to have a global frameloop easy to use alternative, and maybe another primitive that allows you to use other external frameloops (because it would make more sense as a user to use a single one instead of relying on one per library).

Thank you for highlighting those approaches! I'll take a look at that and see what I can do 😄

[royeden]

Opened #824