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