Closed tannerlinsley closed 7 years ago
Hey. Good question.
I find it easier to reason about transitions in Resonance, but this is pretty subjective. I think it's clearer to have a starting state and then the enter, update and leave functions describe how to operate against that state. In my mind it mirrors the logic of doing transitions in D3 and it makes it easier port D3 code into Resonance.
Transition scheduling is probably the largest technical difference between React-Move and Resonance. If you look at the source, transitions are being scheduled against internal Nodes. Resonance is really just surgically slicing out the scheduling mechanism D3 uses against DOM nodes and making it work in React. This scheduling approach is really clever and battle tested. Also, the transition schedules are inspectable just like in D3 which helps with debugging.
By using the same scheduling mechanism D3 uses for transitions, Resonance can handle the same level of complexity. In practical terms, this means being able to define durations, delays and easing on each individual state key (like you would on a DOM element attribute in D3). You can set values, transition to values, transition between two values or use custom tweens. You can do all this and still have the same handling of interrupts that D3 employs.
In terms of performance, both are, I think, doing roughly the same amount of work. If you profile the examples, there's no problem with the amount of work being done in each frame. The real "performance" issue is a problem with React itself. There is no way to guarantee the frame rate when you're calling setState. This is a problem React Fiber is supposed to deal with. Unfortunately, it is taking WAY longer than I anticipated for this to land.
Thoughts?
I actually really like some parts of the resonance API. It certainly adds more fine-grained control over staggering and affecting different keys in different ways.
React-Move does have its Animate
component, which I find particularly valuable.
One thing I feel both resonance and react-move are lacking is a very clear way to chain animations. With the current version of React-Move, you would end up needing to schedule multiple update
states on your own, and with resonance, it looks like you would need to set the delay to the cumulative duration of any previous animations. I would love to see a timeline option of sorts (in both libraries) that would allow passing multiple states with timings that are relative to the previous state. Greensock has a lot of this, and I've seen it come through a bit more in projects like react-flight. You should join the React-Chat slack group so we can chat some more. I think we both have great ideas that could help each other out :)
I'm curious of the advantages or shortcomings when compared to react-move. How does performance stack up?