I've seen (in another article) coding using Redux and code using Context side by side, and I noticed how similar they actually were - the version using Context also used immutability, reducers, actions etcetera ... the amount of boilerplate saved was minor. Coupled with the fact that, as your application gets bigger, you probably want Redux anyway, I wonder why then not choose Redux right away.
On thing that make Redux complex to work with is managing and manipulating state in an immutable way, which gets complex fast. But the funny thing is that you have to do it anyway, also with Context and with useReducer. The code to manage state immutably can get hairy fast but there are tools/libraries to make this easier.
(one complexity that I feel Redux does have is in its numerous "side effect" management libraries such as Thunks and Sagas, this is adding to the learning curve)
But one thing is absolutely true, you're right that you highlighted this: don't push state into Redux which you can just as well make component-local! I think that's where the biggest pitfalls are.
The good news is that our official Redux Toolkit package eliminates all the "boilerplate" around using Redux. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once It also sets up the thunk middleware by default, catches accidental mutations, and more.
I just published a brand-new "Redux Essentials" core docs tutorial, which beginners "how to use Redux, the right way", using our latest recommended tools and practices like RTK and the React-Redux hooks API. I'd encourage you to check it out:
That's brilliant, just incredible, I wasn't aware of these tools and documentation.
Right, I see that immer is included, Redux Thunks is included by default, there are standardized ways of creating the store, actions, reducers ...
This makes everything so much simpler, in large part because it's opinionated, which cuts out huge amounts of discussions, confusion, and "choice fatigue". I say it's about time ... discussion, flexibility and "choices" are nice, but productivity and speed are nicer!
Redux has really matured, so I know what I'll choose for my next project.
Great article, some fantastic points.
I've seen (in another article) coding using Redux and code using Context side by side, and I noticed how similar they actually were - the version using Context also used immutability, reducers, actions etcetera ... the amount of boilerplate saved was minor. Coupled with the fact that, as your application gets bigger, you probably want Redux anyway, I wonder why then not choose Redux right away.
On thing that make Redux complex to work with is managing and manipulating state in an immutable way, which gets complex fast. But the funny thing is that you have to do it anyway, also with Context and with useReducer. The code to manage state immutably can get hairy fast but there are tools/libraries to make this easier.
(one complexity that I feel Redux does have is in its numerous "side effect" management libraries such as Thunks and Sagas, this is adding to the learning curve)
But one thing is absolutely true, you're right that you highlighted this: don't push state into Redux which you can just as well make component-local! I think that's where the biggest pitfalls are.
The good news is that our official Redux Toolkit package eliminates all the "boilerplate" around using Redux. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once It also sets up the thunk middleware by default, catches accidental mutations, and more.
I just published a brand-new "Redux Essentials" core docs tutorial, which beginners "how to use Redux, the right way", using our latest recommended tools and practices like RTK and the React-Redux hooks API. I'd encourage you to check it out:
redux.js.org/tutorials/essentials/...
That's a nice move!
That's brilliant, just incredible, I wasn't aware of these tools and documentation.
Right, I see that
immeris included, Redux Thunks is included by default, there are standardized ways of creating the store, actions, reducers ...This makes everything so much simpler, in large part because it's opinionated, which cuts out huge amounts of discussions, confusion, and "choice fatigue". I say it's about time ... discussion, flexibility and "choices" are nice, but productivity and speed are nicer!
Redux has really matured, so I know what I'll choose for my next project.
Yep, that's exactly why we created Redux Toolkit :)