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.
> I think it's maybe unfair to view Context as a replacement for Redux.
That pretty much sums up why I wrote this article :) After the new Context API came out, a lot of people started saying that it would replace Redux, and like you said, they only really overlap in that they can help avoid prop drilling. Redux is more powerful, out of the box anyway.
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
> 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).
There’s a risk that people will start using context everywhere as a minor convenience. This is the reason the React devs kept the original API so obscure.
I try and limit context to the things that are used across the app, but are not coupled to a given component. For example the user’s session, environment specific behaviour, or theme information.
Most of the time I feel that global-ish data like that shouldn't be passed/exist in the first place. Context is a doubly dangerous place for it, since it can go stale.
I take that back. I'm am accessing this kind of data - via the actions I'm passing down. They are `getStore`ing anything they need.
Anything else that needs to have the data >should< access via props, or the redux store is no longer the single point of truth.
Footguns, footguns, everywhere.
And us, with four left feet.
Have you tried MobX? I feel somewhat the same, and I’m that way MobX has been a good in between for my work involving web interfaces. It’s been extremely easy to implement into older projects using no globalized state as well.
We use MobX as a dependency injector, and it’s been great. Scales up very well and is fairly simple to get people up to speed when they drop into our project.
Redux was a “wtf” as it grew in our app and was a real struggle to back out of.
My current personal project is a video game drum controller trainer that I am writing in Bacon.js streams instead of redux. So far it's been a mindbending experience - I'll have to master it before I know if it's any good :)
