Optimizing with shouldComponentUpdate

Whenever a component's state changes, React rerenders the component and all its children. Often times, the component and its children barely change yet we need to render everything. This seems inefficient, doesn't it?

Remember that React works with a virtual DOM, only interacting with the actual DOM when needed. If one render pass results in the same contents as the previous render, it is a no-op with respect to DOM interactions. If you want to take an even shorter shortcut, the component lifecycle hook shouldComponentUpdate lets you bypass rendering the virtual DOM completely.

React.createClass({
  shouldComponentUpdate: function(nextProps, nextState) {
    // You can access `this.props` and `this.state` here
    // This function should return a boolean, whether the component should re-render.
    return false;
  },

  render: function() {
    ...
  }
});

In Use

Notice by implementing shouldComponentUpdate, we are able to avoid rendering (and calling superExpensiveFunction) when it isn't needed.

Let's look at how shouldComponentUpdate is used in React's source. It reads, perform the update unless shouldComponentUpdate is implemented and returns false. If shouldComponentUpdate returns false, React acts as if the component's render output is the same as the previous pass and returns early. Notice that by bypassing render, the component's children are also skipped as well as some lifecycle hooks. Using forceUpdate does not check shouldComponentUpdate.

Premature Optimization

If we assume that JavaScript is fast, then we shouldn't use shouldComponentUpdate unless we notice performance issues and suspect over-aggresive rerendering as the culprit. Using shouldComponentUpdate adds code complexity and more surface area for bugs to appear, especially ones that are hard to debug. If you have one take away from this article, only use shouldComponentUpdate if you know you need it.

But Performance

There are two reasons why you may want to optimize with shouldComponentUpdate.

• You have used profiler tools and it is telling you that there is significant wasted time rendering for nothing.
• You are able to make strong guarantees about when a component can and cannot change. See PureRenderMixin. With immutability guarantees, shouldComponentUpdate makes a lot of sense. Related: immutable-js and React's immutability helpers.

Parting Caution

Incorrect usage of shouldComponentUpdate can lead to more trouble than it's worth. Think of shouldComponentUpdate as a hint that makes React components smarter. However, if this hint is wrong (or ever becomes wrong), the component may stop working completely.

As an exercise, uncomment shouldComponentUpdate in the following Counter component and notice that Toggle Border does not work anymore. Why not?