I’ve been wondering about the PureComponent everywhere approach for a while.
Eliezer Steinbock
1

PureComponent’s allow you to short circuit the rendering of a component branch by checking if the current props / state are shallowly equal to the nextProps / nextState in shouldComponentUpdate. However, the equality comparison is not free, and has to be done on each re-render.

So if shouldComponentUpdate returns true, then the re-render still has to happen, which means that actually made your app less efficient by adding the additional work in shouldComponentUpdate.

However, the big gains come from when shouldComponentUpdate returns false, especially for components higher in the component tree, because you avoid having to create the element tree for that component and all of its descendants.

So there isn’t a black and white answer on when a PureComponent should be used. As with any sort of optimization, you have to profile the code and see if using it will be beneficial for you.

I think Ben is advocating for using PureComponents in a few places (probably high up in the component tree) so you get the biggest wins, and avoid the penalty of having to do shouldComponentUpdate in all of your components.

The approach that we are currently testing out is the opposite, which is put PureComponents everywhere, and remove it from places where we are doing wasteful shouldComponentUpdate. This is a newer approach and it might not work out, but we’ll post our results in a followup post.

Hope that helped!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.