[dmnd]

Hi Ben! At the React conference, I asked Sebastian Markbåge (also a React author) why `PureComponent` wasn't the default and he said there were already too many new concepts when React was released, and it would have made adoption harder. But he implied that maybe it should be the default. (Then again, alcohol was involved so I could be misremembering.)

When using immutable data structures the comparison in `shouldComponentUpdate` is very cheap. Assuming that, using pure components everywhere is very tempting for simplicity.

Correct me if I'm wrong, but React creates an object for every component to pass props around. Constructing that object is linear in the number of props. An additional `shouldComponentUpdate` check for each component is also linear in the number of props. So using pure components everywhere is at worst adjusting the constant.

Also, in a world where PureComponent is the default, perhaps React could monitor the "hit rate" of `shouldComponentUpdate` and decide to not call it if a component returns true too often?

[sophiebits]

> When using immutable data structures the comparison in `shouldComponentUpdate` is very cheap. Assuming that, using pure components everywhere is very tempting for simplicity.

PureComponent always uses === on each prop value (regardless of type), so the comparison cost with PureComponent should be relatively flat regardless of whether you're using (persistent) immutable data structures. There's also a cost in looping over the prop values and indexing into the (megamorphic) hash map for each props object that is harder to quantify.

> React creates an object for every component to pass props around. Constructing that object is linear in the number of props. An additional `shouldComponentUpdate` check for each component is also linear in the number of props. So using pure components everywhere is at worst adjusting the constant.

That's true. We've just been a little wary of ending up in a "death by a thousand cuts" scenario where every single unnecessary PureComponent makes your app a little bit slower. A number of teams at Facebook have also chosen to use PureComponent for most use cases so you're not alone.

> Also, in a world where PureComponent is the default, perhaps React could monitor the "hit rate" of `shouldComponentUpdate` and decide to not call it if a component returns true too often?

That would be cool, doing a sort of "profile-guided optimization" for React trees. I don't think this would be feasible to give improvements at a per-user/per-session level but could potentially give significant wins if you had a way to collect stats across many different users.

[dounan]

I've updated the post to say 'in the right places' instead of 'everywhere' until we get some profiling data.

[korm]

> When using immutable data structures the comparison in `shouldComponentUpdate` is very cheap.

The equality check is always the same in pure components. Whether the data is immutable or not, pure components do a reference equality check. This will result in failing to update correctly with mutable data.

For simplicity, I guess you could go with PureComponent by default, and remove it as an optimization instead, which is what I've been doing with good results.