Refactoring an App to Use Redux

[00:00:00]
>> Steve Kinney: That was effectively, at this point, we've learned really all the methods of Redux, right? We've learned effectively the kind of surface level depth of React and Redux, right? We've seen the provider, we've seen Connect, right? We've seen we can have a nicer syntax for mapDispatchToProps. If you don't need to pass any state, let's say hypothetically, we had a new list input field where they're only typing in the name of the new list.

[00:00:32]
And then we're like, dispatching that action to state. You can leave this as null for the first argument. And only pass dispatch. If there's no actions that need to happen and you only wanna display stuff, you can just omit this one completely, right? Cuz like, to get to the second argument, you gotta pass null in as the first argument.

[00:00:50]
If you don't need to map any DispatchToProps, you can omit it completely right? So we've got the kind of surface level API for both. We're gonna spend a quick aside, talking a little bit about when to and not to use Redux kind of hold on to your state.

[00:01:07]
And then we're gonna talk a little bit about normalizing data, right? Which will solve some of the problems that we had in the prequel to this course where we were trying to sit there and do a lot of destructuring objects to try to replace them with immutable versions.

[00:01:22]
And we're actually gonna write some helpers to make that a little bit easier today. But first we'll talk a little bit about when to and not to use it. So, Redux seems pretty great, so I've hopefully sold you on the idea of passing in an entire object and getting a deterministic state of your application, it's great.

[00:01:41]
But a lot of times, we have to think about the model state, the actual data in our application, and some input field that we can afford to lose, right? Does that need to go through the whole Redux flow, is a really good question, right? And there is an interesting blog post from a few years ago by a gentleman named Dan Abramov, called You Might Not Need Redux.

[00:02:04]
You may remember him as coauthor of Redux. [LAUGH] Right, and thinking about like, Redux adds some structure. Like I said, I'm a big fan, but it also adds a certain layer of indirection and stuff along those lines. So here we could have something, this is an input field for creating a new item, which is your list, right?

[00:02:25]
We can kinda keep it all in one component, it's relatively simple. If we're kind of doing Redux right, and kind of breaking stuff out into the files. It is likely now gonna be four files to have like the input field on a new to do list. Now, in a small application, I don't think that makes a lot of sense.

[00:02:46]
But in a larger application, having a structure being able to break stuff up might make a lot of sense. Especially when multiple components, like the advantage of having, I can just keep it all in that one component. You lose that advantage as soon as you need that state or those actions in multiple components, right?

[00:03:03]
You end up having to either pass them to the tree or along those lines. This point you can wrap any component that needs a given piece of state for that Redux tree or a given action. You wrap that component in it. It can then modify the state that's entirely separate from your component hierarchy.

[00:03:17]
So, this.setState and the useState React hook are simpler. And maybe for stuff that isn't needed by other components, still the right choice, right? You don't have to go whole hog one or the other. You can choose to like mix and match where it's appropriate. At one point in our code base, we were using regular, old React state, Redux, as well as MobX, right?

[00:03:42]
And I kind of like mixing and matching all of them where appropriate, and those are all like things that you can kind of combine together. All right, so we'll talk a little bit about normalizing our data, right? And in the previous course, we struggled with it cuz our data was not normalized, right?

[00:03:58]
And what does it mean to normalize it? Basically trying to make sure that we kind of separate everything out. And that we're able to like modify just one thing without having like, if you like, a card is a child of a list in a con bond board where it was what we're gonna work on.

[00:04:14]
Then you have to like modify the list and replace the list if you're just changing the name of a card. And you also don't want to be able, you don't wanna like, think too much about having to like find stuff. And so the kind of general principles that we had before.

[00:04:31]
And you don't want duplicated data. The general principles that we had before are kind of prefer objects over arrays. And we'll actually have a few arrays in here. But an object is way easier to access than if you need to get a given particular item out of an array.

[00:04:46]
You're effectively gonna have to iterate to the entire array to find it, right? Are you the one with the idea I'm looking for? Are you the one with the idea I'm looking for, so on and so forth. If you use an object, you're able to say hey, I need the one of this key, right?

[00:04:59]
Where the key of the object is the IDs. And the values of the objects, you can go find it like effectively like, no matter how big it grows, you can find it immediately, right? I like to joke that for any kind of like, programming question at any of the really big tech companies.

[00:05:15]
They give you the code challenge and interviews, the answers always like implemented as a hash map or an object. That is always the answer, every single time. So as a freebie for you. But it also makes sense cuz it's easy to find a given object out of there.

[00:05:27]
Do you need to remove it, just remove that key from the object. You'd have to go and like filter through everything, so on and so forth.