In my personal experience you should use it only when it's necessary. I found using it almost always a solution to another slow thing. Let me give you a real example:
In a project I worked there was a list of comments (similar to this same list), it rendered 10 comments with all of his sub comments and then using infinite scroll it was loading more comments (and sub comments), but the render was too slow, specially after I loaded more pages of comments (the second time I loaded more comments the page took 10 seconds to update, in that time it was completely blocked).
My first attempt was implement shouldComponentUpdate for each component, and it worked, but after deploying that I investigated more and discovered the code was applying highlight.js to the whole document after each component was rendered and in a sync way, this was causing the super slow render.
So I could have used shouldComponentUpdate and call it a day, but if I did that I was never going to found the real issue.
React is already trying to update the DOM as little as possible, so you don't really need to care about your render method being called many times because it should be fast enough. Also implementing shouldComponentUpdate in any component could cause some unexpected issues like this:
You have a component A rendering a component B, both components are stateful. If A is a PureComponent (or manually implement shouldComponentUpdate) and B change it own state since A is not being updated (its state and props didn't changed) it's going to say that it does not need to update, which cause B not to update (because the React's rendered is going to stop traversing the internal component tree of A).
Another possible issue of using shouldComponentUpdate always is that you're adding more logic which need to be run every time something update, e.g. if your render method take let's say 100ms to render and now you need to run another 100ms logic inside shouldComponentUpdate to check if it should render it means you're still going to wait 100ms always and if the component needs to update it going to take 200ms to do it. Now imagine this everywhere.
tl;dr: only use shouldComponentUpdate if you measure you really need it and not always.
Thank you for this good, detailed answer. So, I won't consider using it unless I'm certain of it makes the application better. Using like a very sharp knife, use it only when necessary :)
I'm provably misunderstanding something when you said:
You have a component A rendering a component B, both components are stateful. If A is a PureComponent (or manually implement shouldComponentUpdate) and B change it own state since A is not being updated (its state and props didn't changed) it's going to say that it does not need to update, which cause B not to update (because the React's rendered is going to stop traversing the internal component tree of A).
^^ I agree with this. I’d also note you probably want to use PureComponent when you optimize instead of manually writing shouldComponentUpdate. Then verify with React DevTools (“highlight updates” checkbox) and Performance tab in Chrome (“User Timing” section) that the components don’t re-render anymore. Because the worst thing you can do is to add a shouldComponentUpdate but not verify that it actually bails out when expected.
In my personal experience you should use it only when it's necessary. I found using it almost always a solution to another slow thing. Let me give you a real example:
React is already trying to update the DOM as little as possible, so you don't really need to care about your render method being called many times because it should be fast enough. Also implementing
shouldComponentUpdatein any component could cause some unexpected issues like this:You have a component A rendering a component B, both components are stateful. If A is a PureComponent (or manually implement
shouldComponentUpdate) and B change it own state since A is not being updated (its state and props didn't changed) it's going to say that it does not need to update, which cause B not to update (because the React's rendered is going to stop traversing the internal component tree of A).Another possible issue of using
shouldComponentUpdatealways is that you're adding more logic which need to be run every time something update, e.g. if your render method take let's say 100ms to render and now you need to run another 100ms logic insideshouldComponentUpdateto check if it should render it means you're still going to wait 100ms always and if the component needs to update it going to take 200ms to do it. Now imagine this everywhere.tl;dr: only use
shouldComponentUpdateif you measure you really need it and not always.Thank you for this good, detailed answer. So, I won't consider using it unless I'm certain of it makes the application better. Using like a very sharp knife, use it only when necessary :)
I'm provably misunderstanding something when you said:
Why should B not update? Is this what you meant? codesandbox.io/s/ol4zllpj19
^^ I agree with this. I’d also note you probably want to use
PureComponentwhen you optimize instead of manually writingshouldComponentUpdate. Then verify with React DevTools (“highlight updates” checkbox) and Performance tab in Chrome (“User Timing” section) that the components don’t re-render anymore. Because the worst thing you can do is to add ashouldComponentUpdatebut not verify that it actually bails out when expected.Thank you for your answer Dan. I am definitely going to consider using PureComponent instead of shouldComponentUpdate, if I need it of course.