|
|
|
|
|
|
by seph-reed
1778 days ago
|
|
|
If you're animating using just css classes (or transitions), you'll be fine. Some animations need to be run in javascript though, and doing that through state is a bad idea. You can use ref, and sometimes that's fine, but if the data is changing (hitting a moving target), then you need communication. Think coach-marks and scrolling at the same time. And "tweening" views means showing the last view fade out while the next one fades in (or scrolls in, etc). This means displaying an old state, and a new state at the same time. The trick is to recycle your html elements, but it'll fight you for it. |
|
|
No, the trick is not to use React for animations in the first place.
It's simply not a good a idea to use regular React state for very short-lived data (like animation state) as React will end up re-rendering everything all the time, leading to a significant performance penalty. Instead, I would rather decouple the animated DOM elements from React's state & change handling and just use e.g. d3 to control them. (Yes, it's not pretty but animations have never been pretty in the first place.)
Speaking of (not) using React for short-lived data, this reminds me of another common pitfall: Forms. Many tutorials online blindly recommend binding every HTML input's value to a React state variable using onChange, usually causing the entire form to get re-rendered upon every single key press(!) No wonder the Web is so slow these days…