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're going to structure our app into components. Deciding what to put into one component and what to put into another is one of the hardest problems in engineering.

Entire books have been written on the topic, but here's a rule of thumb that I like to use: if you have to use the word "and" to describe what your component does, then it should become two components.

Once you have those two components, you can either make them child components of a bigger component, or you can make them separate. The choice depends on their re-usability and often mimics your design structure.

For example, our tech salary visualization is going to use 1 very top level component, 5 major components, and a bunch of child components.

 - `App` is the very top level component; it handles everything
 - `Title` renders the dynamic title
 - `Description` renders the dynamic description
 - `Histogram` renders the histogram and has child components for the axis and histogram bars
 - `CountyMap` renders the choropleth map and uses child components for the counties
 - `Controls` renders the rows of buttons that let users explore our dataset

Most of these are specific to our use case, but `Histogram` and `CountyMap` have potential to be used elsewhere. We'll keep that mind when we build them.

`Histogram`, `CountyMap`, and `Controls` are going to have their own folder inside `src/components/` to help us group major components with their children. An `index.js` file will help with imports.

We'll use a `Meta` folder for all our metadata components like `Title` and `Description`. We don't *have* to do this, but `import { Title, Description } from './Meta'` looks better than doing separate imports for related-but-different components. Namespacing, if you will.

Each component should be accessible with `import My Component from './MyComponent'` and rendered with `<MyComponent {...params} />`. If a parent component has to know details about the implementation of a child component, something is wrong.

You can read more about these ideas by Googling ["leaky abstractions"](https://en.wikipedia.org/wiki/Leaky_abstraction), ["single responsibility principle"](https://en.wikipedia.org/wiki/Single_responsibility_principle), ["separation of concerns"](https://en.wikipedia.org/wiki/Separation_of_concerns), and ["structured programming"](https://en.wikipedia.org/wiki/Structured_programming). Books from the late 90's and early 2000's (when object-oriented programming was The Future™) are the best source of curated info in my experience.

---

Congratz! You know everything you need to build visualizations with React and D3. :clap:

This is the point in tech books where I run off and start building things on my own. Then I get frustrated, spend hours Googling for answers, and then remember, "Hey! Maybe I should read the rest of the book!"

Reading the rest of the book helps. I'll show you how all this stuff fits together into a larger project.

Structuring your React app