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