Hi, I’m Swizec Teller. Over the years I've helped over 10,000 engineers hone their craft. 

With React+D3v4 you'll learn the basics of building fast data visualization components in about an hour. Get started immediately without installing anything.

I based React+D3v4 on 20 years of experience with learning how to code on my own, reading blogs and articles, listening to professors, and working with mentors.

Don't know React? React+D3v4 starts at the very beginning.

Struggling with D3? Every function is explained.

Christina

I bought your course Because D3.js is highly flexible, and writing a bunch of method chaining sucks for D3

Frontend Engineer

Francois

I'm a react veteran who has always wanted to learn D3. I know enough about it to know there will be some quirks integrating with react, so figured your book would save me and my team from having to figure those out on our own. 

I use React because it is the sane way of doing things. I use D3 because I have to. I want nice interactive charts. I want to stay sane.

Software Engineer

Amit

In my old age, I love having practical examples to help me learn new things faster.

D3's docs alone are okay but marrying them with React (as a react newbie) is not as straightforward as someone handholding you through the process. And, since I don't have hours after work or on weekends to hack on things like I used to before I was married (or had kids), I need to optimize my learning.

I already owned your previous version and know it would be worth my money to buy the updated version.

Thanks for all of the hard work!

Freelance Engineer

Become a data visualization engineer with React + D3v4

We've been using SVG to render our apps so far. SVG is great because it follows a familiar structure, offers infinitely scalable vector graphics, and works pretty much everywhere. Sure, you can't use some fancy SVG features on all browsers, but the basics are solid.

However, SVG has a big flaw: it's slow.

Anything more than a few hundred SVG nodes and your browser will struggle. Especially if you want to animate those thousands of elements.

A panelist at ForwardJS once asked me, *"But why would you want that?"*. It was my first time participating in a panel, and my answer sucked. What I  *should* have said was, *"Because there have been thousands of UFO sightings, there are thousands of counties in the US, millions of taxi rides, hundreds of millions of people having this or that datapoint. And you want to show change over time."*

That's the real answer. Sometimes, when you're visualizing some data, you have a lot of data. The data changes over time, and animation is the best way to show changes over time.

Once upon a time, I worked on a [D3 video course](https://www.packtpub.com/web-development/mastering-d3js-video) for Packt and used UFO sightings as an example. At peak UFO sighting, right before smartphones become a thing, the animation takes up to 2 seconds to redraw a single frame.

It's terrible.

So if SVG is slow and you need to animate thousands of elements, what are you to do? HTML5 Canvas.

## Why Canvas

Unlike SVG, HTML5 Canvas lets you draw rasterized images. This means you're no longer operating at the level of shapes because you're working with pixels on the screen.

With SVG, you tell the browser *what* you want to render. With Canvas, you tell the browser *how* you want to render. The browser doesn't know what you're doing; it just gets a field of pixel colors and renders them as an image.

As a result, browsers can use the GPU to render Canvas. With a bit of care, you can do almost anything you want, even on a mobile phone.

Phones these days have amazing GPUs and kind of terrible CPUs. That's why I'd almost suggest going straight to Canvas for any sort of complex animation. Mobile traffic accounts for, what, like 60% or even 70% of web traffic these days?

Now, you might be thinking this sounds complicated. How do you know which pixel should do what when you're rendering with Canvas? Sounds like a lot of work.

HTML5 Canvas does offer some shape primitives. It has circles and rectangles and things like that, but they suffer from the same problem that SVG does. The browser has to use your CPU to calculate those, and at around 10,000 elements, things break down.

Notice that 10,000 elements is still a hell of a lot more than the 3,000 or so that SVG gives you.

If your app allows it, you can use sprites: Tiny images copy-pasted on the Canvas as bytestreams. I have yet to find an upper bound for those. My JavaScript became the bottleneck :D

But I'm getting ahead of myself. We'll talk about sprites later.

## The trouble with HTML5 Canvas

The tricky thing about HTML5 Canvas is that the API is low level and that canvas is flat. As far as your JavaScript and React code are concerned, it's a flat image. It could be anything.

There's no structure, which makes it difficult to detect clicks on elements, interactions between elements, when something covers something else, how the user interacts with your stuff and things like that. You have to move most of that logic into your data store and manually keep track.

As you can imagine, this becomes cumbersome. And you still can't detect user interaction because all you get is *"User clicked on  coordinate (x, y). Have fun."*

At the same time, the low level API makes abstractions difficult. You can't create components for "this is a map" or "histogram goes here". You're always down to circles and rectangles and basic shapes at best.

Your code can soon start looking much like the D3.js spaghetti we wanted to avoid in the first place.

We've been using SVG to render our apps so far. SVG is great because it follows a familiar structure, offers infinitely scalable vector graphics, and works pretty much everywhere. Sure, you can't use some fancy SVG features on all browsers, but the basics are solid.

However, SVG has a big flaw: it's slow.

Anything more than a few hundred SVG nodes and your browser will struggle. Especially if you want to animate those thousands of elements.

A panelist at ForwardJS once asked me, *"But why would you want that?"*. It was my first time participating in a panel, and my answer sucked. What I  *should* have said was, *"Because there have been thousands of UFO sightings, there are thousands of counties in the US, millions of taxi rides, hundreds of millions of people having this or that datapoint. And you want to show change over time."*

That's the real answer. Sometimes, when you're visualizing some data, you have a lot of data. The data changes over time, and animation is the best way to show changes over time.

Once upon a time, I worked on a [D3 video course](https://www.packtpub.com/web-development/mastering-d3js-video) for Packt and used UFO sightings as an example. At peak UFO sighting, right before smartphones become a thing, the animation takes up to 2 seconds to redraw a single frame.

It's terrible.

So if SVG is slow and you need to animate thousands of elements, what are you to do? HTML5 Canvas.

# Why Canvas

Unlike SVG, HTML5 Canvas lets you draw rasterized images. This means you're no longer operating at the level of shapes because you're working with pixels on the screen.

With SVG, you tell the browser *what* you want to render. With Canvas, you tell the browser *how* you want to render. The browser doesn't know what you're doing; it just gets a field of pixel colors and renders them as an image.

As a result, browsers can use the GPU to render Canvas. With a bit of care, you can do almost anything you want, even on a mobile phone.

Phones these days have amazing GPUs and kind of terrible CPUs. That's why I'd almost suggest going straight to Canvas for any sort of complex animation. Mobile traffic accounts for, what, like 60% or even 70% of web traffic these days?

Now, you might be thinking this sounds complicated. How do you know which pixel should do what when you're rendering with Canvas? Sounds like a lot of work.

HTML5 Canvas does offer some shape primitives. It has circles and rectangles and things like that, but they suffer from the same problem that SVG does. The browser has to use your CPU to calculate those, and at around 10,000 elements, things break down.

Notice that 10,000 elements is still a hell of a lot more than the 3,000 or so that SVG gives you.

If your app allows it, you can use sprites: Tiny images copy-pasted on the Canvas as bytestreams. I have yet to find an upper bound for those. My JavaScript became the bottleneck :D

But I'm getting ahead of myself. We'll talk about sprites later.

# The trouble with HTML5 Canvas

The tricky thing about HTML5 Canvas is that the API is low level and that canvas is flat. As far as your JavaScript and React code are concerned, it's a flat image. It could be anything.

There's no structure, which makes it difficult to detect clicks on elements, interactions between elements, when something covers something else, how the user interacts with your stuff and things like that. You have to move most of that logic into your data store and manually keep track.

As you can imagine, this becomes cumbersome. And you still can't detect user interaction because all you get is *"User clicked on  coordinate (x, y). Have fun."*

At the same time, the low level API makes abstractions difficult. You can't create components for "this is a map" or "histogram goes here". You're always down to circles and rectangles and basic shapes at best.

Your code can soon start looking much like the D3.js spaghetti we wanted to avoid in the first place.

Introduction

The Meat Start

Simpler Environment

The New Meat

Animation

Animating React Redux

Speed Optimizations

Conclusion

Appendices

Using canvas