4 ms·
All the PureRenderMixin does is make sure that changes only update the DOM if state or props change. This is the ideal way you should be writing your React com
by andy_ppp 11y ago
All the PureRenderMixin does is make sure that changes only update the DOM if state or props change.
This is the ideal way you should be writing your React components anyway; I can't think of any edge cases where you don't want this (I'm sure they exist though)!
I feel that this is scaremongering without real hard data. I'm happy to be proved wrong, should React be shown to be slower than an app that is updating the DOM with big blocks of innerHTML then reattaching event handlers, for example.
With something like Redux and React you can connect only the parts of your tree that will change and react won't re-compare the whole tree as I understand it.
- spicyj 11y agoIf your shouldComponentUpdate always ends up returning true, then any time spent in that method is wasted, because you have to go update the component after that. And as React becomes more and more optimized, shouldComponentUpdate becomes less valuable. It is rare to have an expensive shouldComponentUpdate that returns true most of the time, but there is definitely a trade-off there that depends on the specifics of how data flows through your app. People like to put it on everything but we (React team) believe that it's probably best to put it in a few well-intentioned places. This tension is something we're actively thinking about.
- andy_ppp 11y agoI'm pretty certain you guys on the React team have lots of increasingly clever ideas to speed up the diffing, not limited to actual functions browser vendors could add in native code that could speed this stuff up. Generally React is 'very fast' to 'fast enough'. A very admirable situation to find yourselves in :-)