Animation

Welcome to the animation section. This is where the real fun begins. Demos that look cool, impress your friends, and sound good at the dinner table.

At my dinner table at least ...

You already know how React and D3 work together, so these examples are going to go faster. You know that we're using React for rendering SVG and D3 for calculating props. You know how to make your dataviz interactive and how to handle oodles of data.

Now you're going to learn how to make it dance. Smooth transitions between states, complex animations, interacting with users in real-time. 60 frames per second, baby!

Animation looks like this in a nutshell:

• render something
• change it 60 times per second

When that happens humans perceive smooth motion. You can go as low as 24 frames per second, like old TVs used to, but that often looks jaggeddy on modern monitors.

You're about to learn two different approaches to building these animations. Using game loops and using transitions.

1. Game loops give you more control
2. Transitions are easier to implement

We're starting with an example or two in CodeSandbox, then building some bigger stuff. No more big huge projects like the tech salary visualization, though. Takes too long to set up and doesn't focus on animation.

Using a game loop for rich animation

Game loops are fun! They're my favorite. They even sound fun: "game loop". Doesn't it sound fun to go build a game loop? Maybe it's because I've always used game loops when building something fun to play with.

At its core, a game loop is an infinite loop where each iteration renders the next frame of your animation.

The concept comes from the video game industry. At some point they realized that building game engines is much easier when you think about each frame as its own static representation of your game state.

You take every object in the game and render it. Then you throw it all away, make small adjustments, and render again.

This turns out to be both faster to run and easier to implement than diffing scenes and figuring out what moves and what doesn't. Of course as you get more objects on the screen it becomes silly to re-render the immovable background every time.

But you don't have to worry about that. That's React's job.

React can figure out a diff between hierarchical representations of your scene and re-render the appropriate objects.

That's a hard engineering problem, but you can think of it this way:

1. Render a DOM from state
2. Change some values in state
3. Trigger a re-render

Make those state changes fast enough and you get 60 frames per second. The hard part then becomes thinking about your movement as snapshots in time.

When something speeds up, what does that mean for changes in its position?