[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?

[notpachet]

I would argue that the people who find themselves maintaining an application that is littered with custom shouldComponentUpdate's (et al) have a clear need for _some_ organizing state management principle, whether that's Redux or MobX or something else.

> 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?

The author specified a performance issue that they're trying to debug, but in my experience it's just as common to waste cycles debugging a "why is my component not updating" issue, which is the flip side of the coin: not enough re-renders, instead of too many. So the way I see it, it is not a performance problem per se, it's a state management problem; poor performance (from spurious rerenders) is just one of the possible symptoms of immature state management.

[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