EDIT: I no longer stand by the sentiment of this post, but the technical concerns that cause PureComponent to frequently fail to prevent renders are still worth understanding. Wasted renders are a big problem in performant React.js code. The React core team came up with a solution: React.PureComponent. Let’s look at how it works, what problems it solves, and what problems it doesn’t solve. So, what is it? PureComponent is exactly like React.Component with one difference: it implements shouldComponentUpdate. This allows it to prevent renders based on some heuristic. PureComponent implements this as a shallow equality check on the new props vs the old props, and likewise for state. So if you have the props ‘a’ and ‘b’, it essentially does the following: This is great in theory because we can prevent expensive renders, drastically improving our performance. But, wait! “This is too good to be true”, I hear you saying. Well… you’re right. We run into issues from these !== checks. Let’s say Foo is a component extending from React.PureComponent. Here are some example uses of Foo: These three examples share the same problem: Foo will always rerender because the shouldComponentUpdate always returns true! In the first two, the shouldComponentUpdate checks if this.props.x !== nextProps.x, and since {} !== {}, and likewise for the .map, it will always see the props as having changed. The same thing happens with the children prop, where this.props.children !== nextProps.children. The minor issue here is that we’re doing the shouldComponentUpdate check with no gain, which is more expensive than the example I gave above because it has to iterate over the keys of both the current and next props objects. The larger issue is that we assume we’ve solved a performance problem, while only making it slightly worse most of the time. Hmm… so how do we prevent needless renders and diffing? A trick! Enter: . react-update-if-changed In this example, Foo is using react-update-if-changed instead of PureComponent. Instead of it checking if this.props.children !== nextProps.children, it just checks the updateIfChanged prop for equality. One equality check; that’s it. There are two remaining problems. We might have multiple values that can change, or one value that should be compared by deep equality. You can use the updateIfChangedEqual={[a, b]} prop in this situation. We still have to compute the <h1> in the above example (but not diff it), which might actually be expensive to compute. See the component in react-update-if-changed which addresses this. UpdateIfChanged React.PureComponent is rarely useful, but don’t give up hope on great performance in React.js! is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Facebook

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

React.PureComponent Considered Harmful

Too Long; Didn't Read

Company Mentioned

Frankie Bagnardi

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

React.PureComponent Considered Harmful

Too Long; Didn't Read

Company Mentioned

Frankie Bagnardi

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES