Redux Stores & Reducers

[00:00:00]
>> Let's take a look at the main event here. The other ones we'll see as well. You can guess what apply, middleware does. We need some action creators before we can bind some action creators, so on so forth. What we'll do at this point is what if we went ahead and let's go ahead and make a store.

[00:00:19]
So I'll go ahead and I will say const store = createStore. And I will just warn you right now this isn't gonna go well. Luckily for us, if you look over on the right, the answer there is pretty good, right? Or at least the error message is pretty good, which is expected the reducer to be a function, right?

[00:00:42]
And so we can kinda see in here, we hit createStore. We can go ahead and we can see that it's expecting a reducer as the first argument. It'll also take some other arguments as well. It's pretty flexible with what it takes. There's only one real requirement that it takes a reducer.

[00:00:59]
Now, I had some questions about use of reducer before. So can anyone give me the kind of high level of what a reducer is?
>> Stuff gets in something comes out.
>> All right, I think that's actually wildly good to work with. So pure function, stuff comes in, stuff comes out.

[00:01:18]
Actually, that works really great. Really two things go in and one thing comes out. And so while reducers seem like, okay, we gave something a fancy name, that doesn't necessarily mean that it is complicated. The kinda high level of what a reducer does is a function where two things go in, the state of the world.

[00:01:37]
So a JavaScript object that represent everything that's happening in your application, right? All the kind of important stuff, whether or not a modal is open or close, maybe not. But any kind of the actual model state of your application is in one giant JavaScript object. And then occasionally, things happen.

[00:01:57]
Users click buttons, network requests come back, different things go on. They change routes within the application, so on and so forth. Things happen, so you take the state of the world, which is a JavaScript object. You take a thing that happened, which is a JavaScript object. And they both go in there together.

[00:02:16]
And only one thing comes out, a new state of the world, right? So if you take everything that's happening, and then you add whatever new event just went down, how does that affect the state of our application? Sometimes the answer is not at all, right? We'll see a new to-do coming on the to-do list doesn't change the current user, okay?

[00:02:41]
So then we return the same user, so on and so forth. But generally speaking, there are different things that happen as events happen in an application. We wanna figure out what that actually means. So all these is a function that takes two arguments. It will take state and action, and it will spit out a new state, all right?

[00:02:58]
And it's just a plain old JavaScript function. So let's go back to kind of our code example before, and we could make one in line. But we could also theoretically just make the world's simplest reducer. And by the world's simplest, I mean a reducer that kinda barely does anything.

[00:03:15]
So we'll say a reducer, and like I said before, it takes the state of the world as the first argument. And we'll come up with some initial state that we'll use in a second. So we'll say initialState = { value: 0 }, and it'll take some action. And all it's gonna do immediately is going to return that state back out.

[00:03:41]
Which what we're basically saying here is, okay, no matter what happens, nothing changes, which is a little pessimistic, but it's fine. We'll improve upon that. We'll make some change in the world in a little bit. So this is a reducer, and if we clear out the sidebar over here, which has been reloading for me a bunch of times.

[00:04:02]
I can even console log the store. And you see we're not getting that error anymore cuz we gave it a reducer. Now, it itself has four different methods as well. And we'll kind of talk about some of those in a second. Does anyone wanna take a wild guess of what replace reducer does?

[00:04:26]
>> I'm gonna take a wild guess and say that it replaces the current reducer. [LAUGH]
>> Tell him what he's won. [LAUGH] Yeah, all it does is that function you passed in, replace reducer takes one argument, which is a new reducer and it swaps it out. Why would you ever wanna do this?

[00:04:44]
We're gonna see, yeah.
>> Is it used for code splitting?
>> Exactly, exactly, it's used for code splitting. Later on, we saw that one of the helpers that we didn't pull in here just yet was combined reducers, right? Cuz you can imagine a world where having one function that controls all the updates to, say, your applications is not gonna scale, right?

[00:05:06]
So combined reducers allows you to kinda split it out into smaller reducers that it then combines. We'll see it in a little bit. But you can see a world where you might have only the initial reducers that you need, that you combined into what you give to redux.

[00:05:20]
And then later on, as they load in more code through code splitting, you would just simply swap out the reducer with one that has the additional reducers combined into it, right? So all it does is it takes one reducer and swaps it out for another one. So now we're even 25% of the way through the store, and we'll see some of these in practice.

[00:05:38]
But let's go for a bonus round real quick, which is what do we think getState does?
>> You get the state?
>> Yeah, you get the state, right? You have a store, it holds the entire state in your application. Occasionally, you're going to need it to determine what should be passed to components, right?

[00:05:57]
So we'll take a look at some of that as well. We need to talk a little bit about what an action is, right? Because one of the things that makes this whole reducer pattern a little bit different is it's not just like we call methods on the store object and it changes stuff, right?

[00:06:13]
We saw in the reducer, the state of the world goes in, the action goes in. Well, how do we tell the store, hey, here's an action, go into the reducer and figure out what you should do about it, right? That's gonna be that dispatch function. So let's go ahead and we'll just make a action real quick.

[00:06:34]
I will actually call this one, just for our own clarity, we'll call it incrementAction, and, Great, this is all that you need for an action. There's only one requirement for actions. That one requirement is that it has a type. Because if you're gonna say that something happened and you're gonna ask the reducer to see if the world changed.

[00:06:59]
It's only polite to tell a redux what type of thing just happened, rather than be like, yeah, something happened. That's not particularly fun. So the only requirement is that there is a type. Now, after that, it is up to you what you wanna put on the rest of that object.

[00:07:17]
However, you can imagine a world where if everyone on your team does whatever you want and puts whatever on an object, you will all slowly learn to hate each other, right? So there are a bunch of ways to handle this. The pattern that we use at Twilio is what's called flux standard actions.

[00:07:35]
Its redux is based on flux. The history lesson is not important. But it's basically just an agreed upon set of properties to put on an action. Again, but only if you need them. The only thing that redux requires is that you have a type. The other things that you might see is a payload.

[00:07:51]
And a payload can be an object or could be, like in this case, we're gonna increment by 5 every time, the payload could be 5. But if there's more than one thing that you need, you can use a JavaScript object as well. So it can be a JavaScript object with many properties.

[00:08:04]
So if you're just saying, okay, I wanna add this to-do to that user, you're probably gonna need to tell the reducer what to-do and what user. But if it's just increment, you can say 5. The other one is meta, which is just kind of any other information about the action.

[00:08:17]
And then there could be possibly an error property if there was some kind of error that you need to know about, right? For the majority of this workshop, we're gonna worry about type and payload, right? Those are the two things that we predominantly care about and we'll use as this goes along.

[00:08:33]
Right now we're only gonna stick with the type.