Signals delayed until first animation frame [question]

[johncant]

Hi @joelburget , it's me again. sorry to be a pain on here! At the moment, the signals appear to get queued when they are triggered, and they are evaluated at the next animation frame, rather than being evaluated instantly. Is there a reason for doing that? Am I likely to trigger all hell to break loose if I change it?

[joelburget]

You're talking about how transitions and animations are all batcher per-requestAnimationFrame? I like the current architecture because nothing can happen until the next animation frame anyway so it's a slight optimization.

My question is why we need to change the architecture. What benefit does it give us?

[johncant]

Well, while trying to make classes composable, unbatching the transitions just turned out to be convenient. I made the state part of the JS React class instance state and I stripped out animations in order to make them part of the state but optional. Without animations, there's no need to have anything running periodically.

Also, surely the set of events that can possibly be emitted will depend on the state (for instance, one particular piece of markup might never emit an enter event, wheras the markup for a different state might). Lets imagine that the user does actions a1 and a2 in quick succession, which should trigger events e1 and e2, but e1 causes a state change that does not emit e2 on a2. Then, batching the transitions could result in e1 then e2 in sequence, where the expected behaviour is just e1.

I really hope that I can reintroduce animations into my branch without sacrificing any performance! The additive animations are very cool.