kentcdodds
commented
6 years ago Hi @igor-ribeiro,
Thanks for the question! So I think that redux is a really powerful way to manage global state in an application. And with react-redux, it makes it so you can side-step the "prop drilling problem" (having to pass props through components that simply need to forward them on, and pass callbacks to update state).
Why I'm not huge on redux though is it adds a significant amount of complexity to your application. And sadly more often than not, newer developers especially will put way more into redux than is necessary (for example, I've seen the "open" state of a dropdown being stored in redux which clearly could have been done more easily in component state). People just use redux way too early, before they even know whether the app they're building will have the problems that redux is intended to solve.
I think that vanilla React can get you pretty far before your application really needs a solution like redux. If you're using the right patterns and practices, then you don't feel the pain redux solves nearly as early. First off, component state is pretty powerful, so you definitely don't need redux to store the "open" state of a dropdown. Just put that in a component and pass props if necessary.
User information is something that I see people putting into redux a lot and it makes sense. But you could also just use a regular module to keep that state. It doesn't change all that often so you probably don't even need to subscribe to updates anywhere in your tree anyway.
If you do have state that changes over time and it needs to be shared, if you need to share state between components, then you could lift state up the tree. If you start to encounter the prop drilling problem then maybe you're breaking up your components too much. There's nothing wrong with a large-ish render method.
If it really is just a matter of too much prop drilling then you could implement your own provider for the state you need to share. Especially with react-broadcast, this is pretty trivial. Just include a simple updater function in the value you're passing around and you've got something pretty simple to follow.
I think that doing these things can get you really far along! That said, there are reasons to use redux before your app/state gets too complex/big. I think the biggest of these is serialization of state. If you need to easily persist and restore the state of the application (maybe with server rendering or something) then redux is a great way to do that. Also the middleware can be pretty powerful.
Until recently I worked on a redux app for 1.5 years and I can tell you that I used the Redux DevTools a handful of times. I never really found them all that useful in my workflow. Time travel debugging wasn't ever super helpful to me personally. I did however very much like a logging middleware that we had (can't remember what it was called). It was really nice to look at the before/after and see which action was messing up state. So debugging that was really nice.
Anyway, I hope that's helpful. I just think that when you're using the right patterns and practices with react, you don't need redux so you can side-step the complexity it adds to your app :)
Good luck!
konekoya
ritchieanesco
ruffle1986
In your "Advanced React Component Patterns" course comments, you commented about not being huge on Redux, can you elaborate on that?