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
> 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).
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!