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
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.
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?
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.
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.)
Precisely what the post describes. Functional components and memoize all the things.