Redux contains a number of different ideas/solutions, and I think it's maybe more fair to view them independently. Redux solves prop drilling via the connect function (technically in react-redux, not core redux), and you might say that Context competes with that aspect. Other aspects of Redux are completely unrelated to Context and also good to understand: a unified immutable state tree transformed via composable pure functions in response to a well-defined set of actions represented as objects. Not that you can't do that with Context, but I think it's maybe unfair to view Context as a replacement for Redux.

Funny, I vastly prefer the simplicity of passing down props over HOC spagetti - even when heavily nested. It is a simple matter to keep things organized and out of your way, and change detection is taken care of by selectors.

I used to think props were good for dynamic components, but with portals available, I rarelyconsider them a good pattern for anything but components shared between applications.

I use context to pass down actions. IMHO, mapping those into state should be deprecated.

I have a very different point of view: HOC are core to my way of doing things, as I try to make each component as self-contained and easy to use (fewer props) as possible. Why would I give a user object to my component when it could get it by itself?

It means that components are more coupled to the state, but way way less coupled between them. Which I find to be easier to work with!

So why use redux at all then? Why not just subscribe to a bunch of selectors?

The last codebase I saw that was written with an HOCs-first perspective was rendering every HOC on every prop trigger. It still gives me the twitches :)

> So why use redux at all then? Why not just subscribe to a bunch of selectors?

Not exactly sure what you mean by that? Selectors are a redux thing for me, I don't understand what you mean by not using redux but subscribing to selectors

> The last codebase I saw that was written with an HOCs-first perspective was rendering every HOC on every prop trigger. It still gives me the twitches :)

I don't see how that's a problem. Just because you render a bunch of wrapper components (one for each HOC)? React is extremely efficient at rendering this kind of components having only one child

https://github.com/reduxjs/reselect

> Just because you render a bunch of wrapper components (one for each HOC)?

Efficient rendering would involve >not< re-rendering the child on every prop render, but only when the relevant props have changed. Connect does a shallow comparison, so all the props need to be immutable for it to work.

You can use immutablejs to make your object props immutable, but this gets messy fast. I have found it easier to use selectors, and have changes land when an actual change happens, rather than checking for them or organizing your data to facilitate change detection (rather than organizing your data to make it easier to think about).