Finally, I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to teach you how Redux works and show our recommended practices:
"Redux Essentials" tutorial: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit
"Redux Fundamentals" tutorial: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns
The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.
It's also worth reading through the Redux "Style Guide" docs page, which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps.
I haven't used it myself, so I can only offer a sort of generic suggestion based on seeing it described.
XState is primarily about "state machines" - having a known set of values for a given set of data, and transitioning between those in predefined possible ways based on events that occur in the system. So, it's the combination of "if in state X, and event Y comes in, transition to state Z".
It's very likely that more apps should be using something like XState for logic that is sort of an ad-hoc or implicit state machine.
As David Khourshid has pointed out numerous times, Redux reducers can be used to write state machines, but most commonly aren't, because the focus is more on the actions / event types rather than "if we're in state X, only handle these cases".
I really like XState, but I don't have much experience of building large apps so don't know practically if it scales in a usable way. My main problem is the state of mind transition from thinking about actions to thinking about states - they aren't quite the same thing. But if you make the switch life somehow seems better!
It's essentially just splitting the thought process down the middle. Our user story might say, "when I click the X button, then the dialog closes". Thus, we start thinking about the implementation in those terms as well. But instead, break it up into:
"when I click the X button, it sets the opened state to false", then without any care for how the state got there, "when state.opened is true, display the dialog".
Once you not only make that transition, but start to do it reflexively, it'll really have you reevaluating how you think about software in general. ALL software is really just a state machine.
A database is a "store", with memoizing SELECTors (pun intended), and INSERT is just an action with type: 'table_name/insert', payload: values.
REST APIs have essentially the same CRUD operations as databases.
At its core, React is just an abstraction around the subscriber model that notifies your components when a value changes. Other subscriber models include Promises, AWS lambda functions, and file watchers. ;-)
As I mention in the article - Redux today is a much better experience than ir was only a few years ago 😊 you’ve done a great job maintaining a very important peoject that’s important for hundreds of thousands of projects across the globe.
That being said, and as I state in the article, Redux is used in many situations where it’s not needed - at least not anymore.
Big fan of your work Mark. I've been following you and your work for quite some time. I recently wrote an article on the Redux toolkit with a use-case. cloudnweb.dev/2021/02/modern-react...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nitpick: one 's' in my last name, not two :)
FWIW, I've written multiple posts on this topic that cover various aspects, from "context vs Redux" to "when does it make sense to use Redux?":
I also recently put together a rough estimate of React state management library "market share". Summary:
Finally, I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to teach you how Redux works and show our recommended practices:
The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.
It's also worth reading through the Redux "Style Guide" docs page, which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps.
Hmmmm xstate at 8%, what do you consider it's role to be and should it be used more?
I haven't used it myself, so I can only offer a sort of generic suggestion based on seeing it described.
XState is primarily about "state machines" - having a known set of values for a given set of data, and transitioning between those in predefined possible ways based on events that occur in the system. So, it's the combination of "if in state X, and event Y comes in, transition to state Z".
It's very likely that more apps should be using something like XState for logic that is sort of an ad-hoc or implicit state machine.
As David Khourshid has pointed out numerous times, Redux reducers can be used to write state machines, but most commonly aren't, because the focus is more on the actions / event types rather than "if we're in state X, only handle these cases".
I really like XState, but I don't have much experience of building large apps so don't know practically if it scales in a usable way. My main problem is the state of mind transition from thinking about actions to thinking about states - they aren't quite the same thing. But if you make the switch life somehow seems better!
It's essentially just splitting the thought process down the middle. Our user story might say, "when I click the X button, then the dialog closes". Thus, we start thinking about the implementation in those terms as well. But instead, break it up into:
"when I click the X button, it sets the
openedstate tofalse", then without any care for how the state got there, "whenstate.openedis true, display the dialog".Once you not only make that transition, but start to do it reflexively, it'll really have you reevaluating how you think about software in general. ALL software is really just a state machine.
A database is a "store", with memoizing
SELECTors (pun intended), andINSERTis just an action withtype: 'table_name/insert', payload: values.REST APIs have essentially the same CRUD operations as databases.
At its core, React is just an abstraction around the subscriber model that notifies your components when a value changes. Other subscriber models include Promises, AWS lambda functions, and file watchers. ;-)
Sorry about your name Mark!
As I mention in the article - Redux today is a much better experience than ir was only a few years ago 😊 you’ve done a great job maintaining a very important peoject that’s important for hundreds of thousands of projects across the globe.
That being said, and as I state in the article, Redux is used in many situations where it’s not needed - at least not anymore.
Editor's Note: The name's been fixed, sorry about that.
Not every day you have to correct a typo of your own name in a tech article.
hah, usually it's someone trying to put a 'c' in there :) Lots of "Erickson"s in the world, not nearly as many "Erikson"s :)
I've met very few "Erik"s and NEVER an "Erick", and yet people try to spell my first name that way all the time. ;)
Big fan of your work Mark. I've been following you and your work for quite some time. I recently wrote an article on the Redux toolkit with a use-case. cloudnweb.dev/2021/02/modern-react...