search

joelburget / react-haskell

React bindings for Haskell
MIT License
351 stars 26 forks source link

Signals delayed until first animation frame [question] #18

Open johncant opened 9 years ago

johncant commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.