Here's how React works, in very broad strokes:

You have some data (props and state) that defines the current state of your program. This data is passed to a rendering function, which creates a virtual DOM representation of the component based on the data. After this has happened, the virtual DOM is diffed against the previously built virtual DOM to see if we should tell the browser to render the real DOM based on the new virtual one.

So the general cycle works like this:

Data was updated -> virtual render -> diff new virtual DOM vs old virtual DOM -> real render if necessary.

However, both constructing the virtual DOM as well as diffing the DOMs takes considerable amounts of time. That's why React offers a short-cut to avoid it, if necessary: shouldComponentUpdate. This lifecycle method is called after your data updates and before the virtual render takes place, allowing you to short-circuit the process if you already know that your data didn't change in a way that changes the resulting DOM.

So with the short-circuit, there are two general pathways. If you know the data didn't affect the DOM:

Data was updated -> return false in shouldComponentUpdate -> nothing more happens.

If you know the data affects the DOM or you're not sure:

Data was updated -> return true in shouldComponentUpdate -> virtual render -> diff new virtual DOM vs old virtual DOM -> real render if necessary.

The value of the tool is that it monkey-patches some React internals to notify you when you have missed a chance to use shouldComponentUpdate properly.

Good explanation, with one nitpick: the diff is done between the _old_ virtual DOM tree and the _new_ virtual DOM tree, not between the virtual DOM tree and the real DOM. That's why you can have a component that renders a single div, and then get the reference to the real DOM node and use jQuery or some other DOM-manipulating library to attach non-React-based DOM elements to the div. As far as React knows, you're just telling it to keep rendering that same div, so nothing needs to change.

Thanks for pointing that out, I've updated my comment to fix the mistake.

So recalculating the virtual DOM is fast, but it does have a cost. The easy way to combat this cost is to realize that if you're doing things right and using pure functions, you'll get the exact same UI if you're state hasn't changed. So if you know the state that feeds into a certain component hasn't changed, you can get much better performance.

This library basically encourages you to use React's "PureComponent", which automatically does that calculation to see if the props have changed for you, thus giving you a huge speedup since only the components that need to update will.

Why isn't PureComponent just default?

A few reasons:

- PureComponent was only added relatively recently.

- While shallow equality comparisons are relatively fast compared to deep equality comparisons, they still burn CPU. There's also a number of reasons why props could have changed, such as object literals being declared in the parent's `render` method, or the component receiving other components via `props.children`. In those cases, the "pure" comparison will fail every time, and be useless.

- There is no "default" per se. Application components explicitly extend a React component base class - either React.Component, or React.PureComponent.

It is not a bullet proof solution. It has its use cases, but a couple pitfalls as well. Using PureComponent as a parent to many Component classes is generally not a good idea. If a child depends on a change from `this.context` it will not re-render unless the PureComponent declares `contextTypes`.

https://github.com/facebook/react/issues/2517

Render does not mean render to the dom, render means render the virtual dom. Rendering the virtual dom still has a cost, so this lib is just lett you know there are situations you can avoid. You can tell React to avoid the render if you'd like

https://facebook.github.io/react/docs/react-component.html#s...

Not really. Diffing and rendering still cost a little, and pointless renders that results in zero differences often indicate a possible performance problem. This tool highlights such situations. If there is no difference after an action, it shouldn't happen.