[jon-wood]

This feels to me like another example of how the drive to use nothing but functional components in React is harming readability. Class based components were allowed to define a `shouldComponentUpdate` method which would be called ahead of rendering to decide whether a re-render is needed.

Having the parent component memoise the component instead feels like a step backwards as we're now asking the parent to carry an understanding of a child component's implementation to decide whether re-renders are needed, rather than allowing the child to communicate that up the tree.

[beaconstudios]

the parent doesn't have to memoise the component though. You can do this:

    export default React.memo(function myComponent(props) {
      // implementation
    });

though you would likely want to set displayName before exporting, in reality.

[jon-wood]

In which case, I stand corrected. I’ve not used React for a while and wasn’t aware that was possible.

[FalconSensei]

But that is still memo-ing, just in a different part of the code. And I'm not sure wrapping all components in React.memo is a good practice, otherwise all components would be memo-ed by default. `shouldComponentUpdate` is more explicit

[ramesh31]

Have you ever dug through a complex heavily nested application trying to debug a performance issue, only to find a custom shouldComponentUpdate method within every individual component? It makes debugging an absolute nightmare.

[brundolf]

I'm not sure why it would. The profiler will tell you exactly which component is the bottleneck, and you could then go inspect that one for the cause.

[ramesh31]

>The profiler will tell you exactly which component is the bottleneck, and you could then go inspect that one for the cause.

And then you have to understand the entire thought process and business logic that led to how the shouldComponentUpdate method for that class is implemented for every bottleneck, where one mistake or oversight can lead to an infinite re-render loop. This is the kind of stuff that should be handled at the framework level or with your state management library, not individual components.

[thrashh]

Yeah but no one should be using shouldComponentUpdate except for rare cases

If you have to consistently replace a framework-managed hook for performance, either the framework is not suited for you, the framework is poorly designed, or you’re using the framework wrong.

[psadri]

What is your proposed alternative?

[ramesh31]

>What is your proposed alternative?

Precisely what the post describes. Functional components and memoize all the things.

[notpachet]

Not the OP, but in a word: Redux.

[nsonha]

no?

If you want state management you use a state management library. If you want optimization, you do memo, or pure component. You don't rely on the fact that some state library does that for you. You don't want your component's performance changes drastically when you refactor to context or whatever

[notpachet]

See my response to another comment in this thread. react-redux manages shouldComponentUpdate on your behalf. That's what's being discussed: the pain that comes from custom shouldComponentUpdate implementations. I almost never have to write custom component lifecycle methods when using Redux.

[nsonha]

The people who have a need for redux should already be using it. Are you telling people with a need to optimize their components to conjure up a need for redux, just so that they can use it to kill 2 birds with one stone?

[kecupochren]

What? Redux doesn't do any performance optimizations.

[notpachet]

Not by itself, but most people who use React + Redux use the (unsurprisingly named) react-redux glue library, too. That does a lot of the "should component update" calculations for you as a function of the computed `map[State/Dispatch]ToProps` result. (There are still some gotchas with caching selectors and so on, but I personally find those a lot easier to implement post-fact than memoizing hook soup codebases once you realize you have a problem.)

[kecupochren]

Oh, I never knew that. TIL