Stay away from PureComponent

Maarten Schumacher
Jul 28, 2017 · 2 min read

PureComponent was recently introduced to the React ecosystem, and it seems like an easy performance win. Just change extends React.Component to extends React.PureComponent and boom!, enjoy your lightning fast app. However there are a few gotchas, and more importantly, some worrying maintenance issues.

What’s wrong with this picture?

Did you spot the error? The images prop passed down from Parent uses an array literal that breaks the PureComponent optimisation because it will always fail the equality check, even though the content of the array is the same. At the moment when you make the choice to implement PureComponent, you of course read up on all the gotchas associated with it and make sure Parent doesn’t pass anything to Child that would unnecessarily cause Child to re-render.

But what about when you refactor this component two months later? What if someone in your team refactors this component? Would they notice that child implements PureComponent, and take the necessary precautions? In this example, Parent and Child are pictured next to each other, but realistically they would be in different files, so it’s easy to miss.

If you break PureComponent in this way, you’re not only removing the optimisation, you actually make the performance worse than it would be without implementing PureComponent, since now you’re running an equality check that always fails. What’s worse, you might not even notice the decrease in performance after your refactor. Your app will just become slower until you take the time to profile it again, at which point you will discover that your previous optimisations have broken.

How to deal with this maintenance issue? One improvement could be to better annotate optimised components. So if you change Child to implement PureComponent, change the name of Child to PureChild, so that it becomes obvious to anyone using this component that they have to be careful what they’re passing into it.

An even better solution would be to not use PureComponent at all, and just use shouldComponentUpdate. Why? Because it will break in a more obvious way. Instead of performance silently getting worse, the component will just not re-render. The developer refactoring the component might still scratch their head and think their logic is broken until they see the shouldComponentUpdate implementation, so a naming convention around optimised components like PureChild might still make sense.

From a maintainability perspective, shouldComponentUpdate is not ideal since you have to change its implementation to see the component re-render, but it’s much better than the silent decrease in performance that PureComponent offers. Obviously though, the most maintainable solution would be not to optimise at all! Always profile before optimising, so you only optimise components that really need it.

Maarten Schumacher

Written by

React Native developer, functional programming enthusiast

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade