Transcript from the "Redux Overview" Lesson
>> Brian Holt: Now, starting with Redux. React and Redux are often mentioned in the same sentence, to the point that there are many people that don't really know where the two separate, right? I have consulted too many companies, they just said well, we used React, so we used Redux, right?
[00:00:15] And they just thought the two just are married together and just go together. That is not the case, that is definitely not the case. You should almost never start a project with Redux out of the box. Unless you have very specific requirements that need Redux out of the box, I would suggest start with just pure React and go until it hurts.
[00:00:33] And then once it hurts, go back and refactor and introduce Redux. You're gonna see in just a second why I say that. When you add Redux to a project, it greatly increases the complexity of the flow of data within your app. The reason why it's good is it makes it very predictable how your data flows, it makes it very testable how your data mutates, right?
[00:00:56] These are desirable things, but it goes from as easy as saying, set state would just react and that's the end of mutating data. You have to go through now five or six steps instead of one step. That should give you pause, I think. So there are benefits, but it's a trade off, there are downsides and they're pretty big downsides in my opinion.
[00:01:36] And you can end up with kind of a mess of a code base because you have a bunch of people contributing to a repo that don't really know how write it very well. Redux requires a bit of discipline as well. So let's talk about what React or Redux is at its core.
[00:01:53] It's a central data store for your entire repo. It's as if you had one React state for your entire repo. That's kind of the gist of what it does for you. Why is this appealing? Well, if you remember from when we talked about context in the previous course.
[00:02:12] It's very convenient if you have multiple different components reading from the same data store. So if you have user data, right, if the user logs in and has their name and address and email, and you need to use that on the settings page, and nav header, because you show them their email and avatar.
[00:02:29] And you're reading this data all over your application, it's really convenient to have some sort of data store that you can read from, right? And you don't have to pass those props everywhere. So if you have problems like that, that's something that Redux can definitely help you out with.
[00:02:43] However, people get a little tempted to throw everything into Redux. I've even seen applications where they've out logged using React state. That is a terrible idea, and you've messed up the entire reason for using React, and honestly you shouldn't even use React at that point, in my opinion.
[00:03:00] That is a giant mistake, to put everything in Redux. So again, Redux can be helpful, but it needs to be well architected and it has to have a lot of discipline around it.
>> Brian Holt: Another reason why I like Redux is it's extremely testable. It's testable at multiple different levels.
[00:03:20] And any time you can have tests around mutating data, that is key, whereas I was kind of low on testing in the testing module for the React components. If you're doing Redux, test everything, top to bottom, right, tons, and tons, and tons of tests. If you're not writing tests for Redux, you're not using it properly.
[00:03:40] And Redux takes a lot of care to make every step of the process very, very testable. Honestly it's probably the most compelling reason to use it.
>> Brian Holt: Lastly, the debugging story on Redux is pretty great. We're gonna get into that at the end of this module here, but let me just give you a little teaser of the phrase time travel debugging.
[00:04:01] That's amazing, and we'll get there, and I'll show you, and it's gonna just [SOUND] blow your mind. Okay,
>> Brian Holt: So when you're doing React and you have React State Management, it's pretty simple. You call setState, and you let React rerender, and that is just the endless cycle of calling setState and letting it rerender.
[00:04:23] And that's a contract by now you should hopefully understand. With Redux we add a lot more to this process. So let me walk you through some steps here. User types in an input box, that calls an action creator to get a well formed action. That action is then dispatched to Redux.
[00:04:44] Redux then inserts that action to a route reducer, the root reducer delegates that action to another correct reducer to handle that sort of action. That reduce returns a new state, and given the old state and the action object, the new state becomes a storage state and then that is fed back into React and calls for us to update with React.
[00:05:05] So I have that here as eight steps, as opposed to one step with React. And I'm being a little generous, too, because if you have anything asynchronous about it, it gets to be more, or if you have to dispatch multiple actions, it can get a little crazy.
>> Brian Holt: But each one of those steps that I just outlined for you is testable, and that's pretty cool.
>> Brian Holt: So this is kind of the thing that we're gonna get into. So you're gonna have kind of multiple different concepts thrown at you all at once, cuz the unfortunate truth of this is you have to set up a lot of the, kind of infrastructure around this to get it to work.