2 things about PureComponent you probably should know.

I hope that you heard that PureComponets, or pure-render-mixin in the past, or shouldComponentUpdate, can improve speed of your application.

Pure something in Pure somewhere.

And I hope that you heard the meanings of Pure keyword in this context.

Pure function will evaluate the same results with the same arguments, and will not produce any side effects (or results MAY be NOT the same).

So pure, pure by any reason and by any technique, component will render the same children with the same props.

That’s how 99.99% of people will understand PureComponent. As a predictable function.

Let’s recall stateless components, which assumed to be a pure function.

But pure functions are not pure components.

Right now stateless component is always impure component. As a result stateless components in many-many cases are slower that stateful components, cos you can optimize “stateful” components, but can’t change the way stateless ones works.

In the same time stateless components are more pure than PureComponents, as long they always do the same job, while PureComponent’s optimization behavior is not pure. Weird, right?

Stateless components (could be) SLOW!

But wait! One said that Facebook promised stateless components to be pure, but not now, may be tomorrow! Yes! Just wait a bit.

That was true for React 15. It is not true for 16

How PureComponents works?

React gives you the ability to optimise component, by implementing shouldComponentUpdate function.

Next, you can decide should you re-render it on props and state change, or not.

Pure-render-mixin or PureComponent just implements this function for you. And it is just impossible to generate it for a stateless component as long it is not a Component. It is just a function.

Or possible? Actually, React uses that stateless component indirectly and it can perform necessary checks in Component Adapter. Actually — stateless components are very complex thing, and React expects them to be pure functions. If not… oh, even don’t try.

So, the only question here might be a bit strange —

Why “purifying" of stateless components is..

..not enabled by default?

How Pure is a Pure component?

The answer lies in math.

if f(X) produces Y, then `f` will be `pure`, when with the same X `f` will generate the same Y.

With absolutely same X will produce absolutely same Y. Including a whole nesting component tree.

So, if you are a PureParent you have to think shouldIUpdateMyself, but also you have to think shouldIUpdateAllMyChildren.

So, you have to be a good parent.

In some situations you can think about direct children, but not for the ALL. Especially if you a just a component, and do not own some necessary knowledge.

And the second problem, that you should not only think about props and state — you also have to think about context. And to think about context you have to declare contextType, so you have to specialize that are you "thinking" about. Imho, it is impossible.

In this case — “you” have no rights to be a PureComponent and stop updates, just anything could be placed inside, and might dont know — what.

This might become even more severe with render props, as long pure components could lead to different function scopes visible from different function-as-children, as long those functions were memoized(freezed) in the different (sometimes random) renders.

Conclusion

Pure components keep your application fast. Sometimes — more predictable, but often — less predictable, as long they change the way application works. The way it flows.

Stateless components are not pure, and may run slower than PureComponents by any kind. But usually this is not something you should think about. They are made from pure functions and they are predictable.

But… if you very wish to create a fast application with good user experience — you have to use Pure Component, or shouldComponentUpdate (sCU).

And the only way to use them — as a “event propagation boundaries”. Predictable “event horizons” in predictable places. To be the start of any update(as redux or Context API), and to be the end for anything “unexpected”. “Unpredicted”. “Unwanted”. “Unknown”.