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

Containers are React components that talk to the Redux data store.

You can think of presentation components as templates that render stuff and containers as smart-ish views that talk to controllers. Or maybe they're the controllers.

Sometimes it's hard to tell. Basically, presentation components render and don't think, containers communicate and don't render. Redux reducers and actions think.

I'm not sure this separation is necessary in small projects. Maintaining it can be awkward and sometimes cumbersome in mid-size projects, but I'm sure it makes total sense at Facebook scale. We're using it in this project because it's the officially suggested way.

The gist of our `AppContainer` looks like this:

// src/containers/AppContainer.jsx
import { connect } from 'react-redux';
import React, { Component } from 'react';
import PropTypes from 'prop-types';

import App from '../components';
import { tickTime, tickerStarted, startParticles, stopParticles, updateMousePos, createParticles } from '../actions';

class AppContainer extends Component {
	componentDidMount() {
		const { store } = this.context;
		this.unsubscribe = store.subscribe(() =>
		    this.forceUpdate()
		);
	}

	componentWillUnmount() {
		this.unsubscribe();
	}

   // ...

	render() {
		const { store } = this.context;
		const state = store.getState();

		return (
		    <App {...state}
		         startTicker={() => this.startTicker()}
		         startParticles={() => this.startParticles()}
		         stopParticles={() => this.stopParticles()}
		         updateMousePos={() => this.updateMousePos()}
		    />
		);
	}
};

AppContainer.contextTypes = {
    store: PropTypes.object
};

export default AppContainer;


We import dependencies, then we define `AppContainer` as a full-feature React `Component` because we need to use lifecycle methods. Those aren't available in functional stateless components.

Three parts of this code are important:

1. We wire up the store in `componentDidMount` and `componentWillUnmount`. Subscribe to data changes on mount, unsubscribe on unmount.
2. When rendering, we assume the store is our context, use `getState()`, then render the component we're wrapping. In this case, we render the `App` component.
3. To get the store as our context, we *have to* define `contextTypes`. It won't work otherwise.

What I like about React context is that it lets us implicitly pass properties to all children components. Anything can go in context, but if you're not careful, this can lead to rendering stale data.

That's why you should reserve context for passing the Redux store. All components need access, and the store itself is smart enough to handle updates.

### AppContainer talks to the store

Congratz, you know the basics! Now we need to define those callbacks so `App` can trigger actions. Most are boilerplate-y action wrappers. Like this:


We import dependencies, then we define `AppContainer` as a full-feature React `Component` because we need to use lifecycle methods. Those aren't available in functional stateless components.

Three parts of this code are important:

1. We wire up the store in `componentDidMount` and `componentWillUnmount`. Subscribe to data changes on mount, unsubscribe on unmount.
2. When rendering, we assume the store is our context, use `getState()`, then render the component we're wrapping. In this case, we render the `App` component.
3. To get the store as our context, we *have to* define `contextTypes`. It won't work otherwise.

What I like about React context is that it lets us implicitly pass properties to all children components. Anything can go in context, but if you're not careful, this can lead to rendering stale data.

That's why you should reserve context for passing the Redux store. All components need access, and the store itself is smart enough to handle updates.

# AppContainer talks to the store

Congratz, you know the basics! Now we need to define those callbacks so `App` can trigger actions. Most are boilerplate-y action wrappers. Like this:

Introduction

The Meat Start

Simpler Environment

The New Meat

Animation

Animating React Redux

Speed Optimizations

Conclusion

Appendices

1 Container component