hooks. But if we go full physics, we'll have to provide an additional API for the above cases of animation. Every setState will forcefully be queued. I've implemented this here. Sure, you can imagine it as a heavy, horizontal rod placed at the end of the menu that drags it down until the menu stretches too much and bounce back a little; but it actually becomes, imo, difficult to reason about when you're attaching/removing strings. To enable preview, render should become a function of props and state and should not rely on ops and ate: m/facebook/react/issues/1387. Physics need to know more than the little information about begin/duration/whatever that we provide. Furthermore, it just feels more right to automate render to achieve animation (also see stress test 4). A sensible default would be additive animation, which my repo above implements.
Somewhere in the middle. You can have code on arbitrary frames and they'll get executed when it's reached. The state of the app can end up somewhere else after a tween and the frameworks don't seek to control that. This tests the ability of the animation system to compose animation, not in the sense of applying multiple interpolations to one or more variables passed onto the child (this should be trivial but in the sense that the parent's constantly updating at the same time. SetStateArray setStateArray(p(.) Create an array that describes the animation, where each cell corresponds to one frame.