With PureRenderMixin, doesn't that also prevent child components from updating in response to state changes? For example if a child component must update due to some event, but none of its parents care about that event, doesn't that cause the child not to update?
Edit: Turns out my render methods aren't pure. I query stores right render, which causes problems when using this mixin.
An often overlooked pattern in React is controller-views. When using Flux (or really, with any external-to-the-component data) you should put this Store logic in the nearest parent to the components who use it. This component is the "controller" which gets the data and passes it as properties to the child components (who pass it as required to their children down the hierarchy).
This keeps your child components pure (fast, renders directly from props, uses PureRenderMixin) and keeps data access centralised to the nearest common controller-view component. It's okay to have a parent component that simply collects data to pass directly into a single child within the render() call — the parent fetches data and sets props, the child re-renders only when the props update, and there's a clear separation of responsibility between the two.
That's kind of the point, at least as I understand it. You want to minimize the number virtual nodes that need to be reconciled to actual DOM nodes. If nothing about a parent's props or state has changed, then ideally nothing should have to change about any of its children.
If you use PureRenderMixin, all child components must also be pure. If a pure component wants to change what it renders because of an event, it must change its state, otherwise it won't be re-rendered.
Edit: Turns out my render methods aren't pure. I query stores right render, which causes problems when using this mixin.