Animations have for a long time been a weak point of the React ecosystem. The
Animated library aims at solving this problem. It embraces the declarative aspect of React and obtains performance by using raw DOM manipulation behind the scenes instead of the usual diff.
The basic building block of this library is
Animated.Value. This is a variable that's going to drive the animation. You use it like a normal value in
style attribute. Only animated components such as
Animated.div will understand it.
As you can see, the value is being used inside of
render() as you would expect. However, you don't call
setState() in order to update the value. Instead, you can call
setValue() directly on the value itself. We are using a form of data binding.
Animated.div component when rendered tracks which animated values it received. This way, whenever that value changes, we don't need to re-render the entire component, we can directly update the specific style attribute that changed.
Now that we understand how the system works, let's play with some animations! The hello world of animations is to move the element somewhere else. To do that, we're going to animate the value from the current value 0 to the value 400.
On every frame (via
timing animation is going to figure out the new value based on the current time, update the animated value which in turn is going to update the corresponding DOM node.
As a developer, the mental model is that most animations are fire and forget. When the user presses the button, you want it to shrink to 80% and when she releases, you want it to go back to 100%.
There are multiple challenges to implement this correctly. You need to stop the current animation, grab the current value and restart an animation from there. As this is pretty tedious to do manually,
Animated will do that automatically for you.
timing animation doesn't feel good. The main reason is that no matter how far you are in the animation, it will trigger a new one with always the same duration.
The commonly used solution for this problem is to use the equation of a real-world spring. Imagine that you attach a spring to the target value, stretch it to the current value and let it go. The spring movement is going to be the same as the update.
It turns out that this model is useful in a very wide range of animations. I highly recommend you to always start with a
spring animation instead of a
timing animation. It will make your interface feels much better.
It is very common to animate multiple attributes during the same animation. The usual way to implement it is to start a separate animation for each of the attribute. The downside is that you now have to manage a different state per attribute which is not ideal.
Animated, you can use a single state variable and render it in multiple attributes. When the value is updated, all the places will reflect the change.
In the following example, we're going to model the animation with a variable where 1 means fully visible and 0 means fully hidden. We can pass it directly to the scale attribute as the ranges match. But for the rotation, we need to convert [0 ; 1] range to [260deg ; 0deg]. This is where
interpolate() comes handy.
The reason why we can get away with not calling
render() and instead modify the DOM directly on updates is because the animated values are opaque. In render, you cannot know the current value, which prevents you from being able to modify the structure of the DOM.
Animated can offload the animation to a different thread (CoreAnimation, CSS transitions, main thread...) and we don't have a good way to know the real value. If you try to query the value then modify it, you are going to be out of sync and the result will look terrible.
There's however one exception: when you want to stop the current animation. You need to know where it stopped in order to continue from there. We cannot know the value synchronously so we give it via a callback in
stopAnimation. It will not suffer from beign out of sync since the animation is no longer running.
Most animations libraries only deal with time-based animations. But, as we move to mobile, a lot of animations are also gesture driven. Even more problematic, they often switch between both modes: once the gesture is over, you start a time-based animation using the same interpolations.
Animated has been designed with this use case in mind. The key aspect is that there are three distinct and separate concepts: inputs, value, output. The same value can be updated either from a time-based animation or a gesture-based one. Because we use this intermediate representation for the animation, we can keep the same rendering as output.
The code needed to drag elements around is very messy with the DOM APIs. On mousedown, you need to register a mousemove listener on window otherwise you may drop touches if you move too fast.
removeEventListener takes the same arguments as
addEventListener instead of an id like
clearTimeout. It's also really easy to forget to remove a listener and have a leak. And finally, you need to store the current position and value at the beginning and update only compared to it.
We introduce a little helper called
HorizontalPan which handles all this annoying code for us. It takes an
Animated.Value as first argument and returns the event handlers required for it to work. We just have to bind this value to the
left attribute and we're good to go.
One of the big breakthrough of the iPhone is the fact that when you release the finger while scrolling, it will not abruptly stop but instead keep going for some time.
In order to implement this effect, we are using a second real-world simulation: an object moving on an icy surface. All it needs is two values: the current velocity and a deceleration coefficient. It is implemented by
The target for an animation is usually a number but sometimes it is convenient to use another value as a target. This way, the first value will track the second. Using a spring animation, we can get a nice trailing effect.
As I said earlier, if you track a spring
It is very common to animate