Store dispatch & subscribe

[00:00:00]
>> Steve Kinney: We have getState, we saw dispatch, right? Let's put a console log inside our reducer,
>> Steve Kinney: That will just console log our action, we'll say, something happened.
>> Steve Kinney: And then we'll take our store,
>> Steve Kinney: We'll dispatch,
>> Steve Kinney: Hi.
>> Steve Kinney: It needs to be a plain object, so,
>> Steve Kinney: Cool, Redux has some rules to it, right, so let's read this one.

[00:00:50]
All right, needs to have a type property, why would it need to have a type property?
>> Speaker 2: So that it knows which reducer to use.
>> Steve Kinney: Yeah, all right, what happened, right, you're saying something happened, right? One of the things that Redux does really well is, it adds some amount of structure and rules, right?

[00:01:11]
And structure and rules is good, [LAUGH] right, for the maintained ability of your code base, right? And luckily, as we can see, this is helpful, did you misspell a constant, so on and so forth. All right, so we know that strings don't work, we found that out with a pretty helpful error message that I cleared.

[00:01:26]
It was like, hey, it needs to be an object, cool, so we given an object. Next helpful error message, yeah, I need to have a type, okay.
>> Steve Kinney: A type is effectively just a string, it's just saying what happened in our application, right? The user requested data, they logged out, something along those lines, that's the type of action that happened.

[00:01:46]
So we'll say type is,
>> Steve Kinney: Cool, and we'll fire that around, and you see now everything works. Let's do that one more time so we can actually see it. There was this action that fired when the store was created, which is kind of an internal one, which is just initializing everything.

[00:02:05]
That prefix would not smash into any of yours unless you have an action called @@redux/INIT, don't do that. And then you can see that we hit the console log where something happened, the first time with that Redux init action, and the second time with our ADD object, right?

[00:02:24]
Now it seemed like Redux had a lot of rules. Really, beyond it being an object and having a type, that's really about it. Everything else is kind of up to you and up to your team, right? However, if I may make some recommendations on how you should structure your actions that we're gonna just do for the remainder of the day.

[00:02:49]
There's this pattern called the Redux standard actions, right, which is type, we know we have to have, right, we got yelled at, fine. Then the other one is, just to make sure that things are consistent, you'll see sometimes a payload. Which will be effectively all the data that comes along with that action.

[00:03:08]
So all right, we heard back from the API, cool, the payload is obviously the API results. Or the user changed an input field that we need to store in Redux, cool, we might put that in the payload. The other one's optional, and at my company, we tend to try to avoid it, which is meta.

[00:03:29]
Which is just other data that isn't important for doing the action. We will use this occasionally for analytics and stuff along those lines, other things that we need to know. But you get some side eye because we're trying to like stay relatively consistent. And at the end of the day, one of the things that I liked is, we got errors when we just started throwing strings, we got errors when we didn't have a type, right?

[00:03:53]
Consistency is really important, and one of the nice things that Redux brings to the table, cuz with the context API in React, you do whatever. Right, there's no rules, which is kind of great, but having some amount of rules is super helpful. Cool, so we have the ability to send an action through.

[00:04:12]
>> Steve Kinney: So what would this look like, let's actually give it a payload.
>> Steve Kinney: We'll give it, sorry, payload, and we'll give that, that doesn't have to be an object. But trust me, the consistency is nice, basically, my rule is that it should be an object. All right, we'll say that the amount, just to give it a separate name, is 2.

[00:04:44]
[LAUGH] It was gonna be 3, but I missed the 3 button. Cool, so now you can see that we've got this type of ADD and amount of 2, great, killing it. We're most of the way through understanding Redux, even if it doesn't feel like that. In here, we can then say, all right, we've got the state of the world, we've got the action.

[00:05:04]
How do we figure out what happened here? So it's basically, look at the action type. If the action.type,
>> Steve Kinney: Is ADD,
>> Steve Kinney: Right, what should we do, we should take the,
>> Steve Kinney: Value, which is state.value. This is a small important part coming here. We'll take the amount,
>> Steve Kinney: action.payload.amount, and then we want to add them together.

[00:05:45]
Now, you might be tempted to do something like state.value = value + amount. Seems reasonable, right, that will get you the correct number, and really, here, it'll probably work.
>> Steve Kinney: We took out the console log there, so we'll just do a,
>> Steve Kinney: store.getState.
>> Steve Kinney: All right, we get the 3, the problem here is, we mutated the object, right?

[00:06:30]
We just did the thing I told us not to do, right, which makes it very unclear. So if we did a,
>> Steve Kinney: store.getState, we'll call this first, and we'll dispatch.
>> Steve Kinney: Second is store.getState.
>> Steve Kinney: Run that, and we'll say first.
>> Steve Kinney: They're the same object cuz we mutated it, right?

[00:07:06]
Which means React cannot tell that we need to re-render anything. It's like, yeah, same thing as before, when we had a 1. Except it's not, right, so we do need to immutably change the objects, right? So for instance, we could theoretically, the easiest way to do this is to make the object by hand.

[00:07:29]
Right, so we say value is now a new object,
>> Steve Kinney: value + amount.
>> Steve Kinney: Right, now they're false, right, and that means that we will actually re-render everything in React, right? The reason that everything's gotta be immutable is not a Redux rule per se. It's a Redux best practice, obviously, but it's not a Redux rule per se.

[00:08:00]
It is, how do any of your frameworks know that anything changed, right? And so if it gets a little hairy at times when we're implementing a larger application, it's not necessarily Redux's fault, it's JavaScript's fault. Sorry, that's where we are on the web, bummer. All right, so at this point, we've used createStore, we've used compose, right?

[00:08:25]
The store we saw had a bunch of methods, real quick, we'll just,
>> Steve Kinney: We'll get rid of these for a second here. And we'll say store.subscribe.
>> Steve Kinney: Cool, and we'll do this a few times, right?
>> Steve Kinney: Not go back and forth in my browser. So store.subscribe will now trigger something every time it happens.

[00:09:04]
Right, we give it a function, store.subscribe also returns a value, which is much like a lot of event emitters, right? It gives you effectively a,
>> Steve Kinney: Whenever you call store.subscribe, it will give you a function that will go ahead and give you the ability to unsubscribe, right? Otherwise you have a giant memory leak when that component unmounts or something along those lines.

[00:09:32]
Right, so we could, for instance, let's actually change this,
>> Steve Kinney: To console.log,
>> Steve Kinney: store.getState,
>> Steve Kinney: value, right?
>> Steve Kinney: Be cool if we ran the most recent code, right, we're adding 3, 5, and 7. Here we'll just call,
>> Steve Kinney: Unsubscribe.
>> Steve Kinney: 3 and 5, right, so we stopped listening.

[00:10:15]
So this gives us the ability, if this component unmounts, that we're not still listening to changes to the store.