Redux Stores & Dispatch

[00:00:00]
>> There is a few things that come up around this, which is why did I have to scream the word increment, right? Does not be I feel very passionately about incrementing a value. I mean, I personally do, but that's not the reason why I typed it all in capital letters.

[00:00:18]
Does anyone have any hypotheses on why by convention use all capital letters for our action types?
>> I have a question, because if you use Redux toolkit and createSlice actions are not all uppercase, right?
>> Yep, that's a great point that and we will talk about that in a second.

[00:00:37]
They don't have to be all uppercase. It's just a convention. And we'll talk about why we tend to use, we're gonna use the all uppercase in the beginning and then we're gonna swap to a different syntax towards the end for a reason that we will get to probably the next 30 or so seconds.

[00:00:54]
Any other guesses?
>> So maybe this type is some kind of constant.
>> Yep.
>> So that's why.
>> Yep, so basically, so one of the things that was just brought up is that, when we use Redux toolkit later, Redux toolkit might do something like this. The action type might be something along the lines of, Counter/increment, right?

[00:01:22]
That totally works. It really can be any string. The convention a lot of times is to use a string and to use a constant, right, to reference that string. The reason for that is let's say hypothetically, we want to say if (action.type is INCREMENT). I almost made my point, is increment then we'll say like state, I will return, State and that will be state.value+1.

[00:01:59]
Right, and this all works, right, we dispatch an action with the type of increment, it would modify the state and increment it by 1. The problem with using strings everywhere is, you almost saw me do it, which is, If I misspell one of those strings, the action of increment will fall through the entire reducer and not hit any of my conditionals.

[00:02:23]
Or if I mistype it in the action it will fall through and not hit any of the conditionals, right? So a lot of times what we'll find ourselves doing is, we'll say, INCREMENT, and then we'll swap these two out. And now when you're using the constant everywhere, if you misspell it you'll get a reference error, right?

[00:02:52]
It'll be like there is no constant called whatever. And the reason we're using all capitals is to separate it from the rest of our variables. We saw before we could use that slash, it's just really hard to write a constant that has a slash and is not valid JavaScript.

[00:03:09]
There is nothing stopping you if you prefer, To write it like that. It doesn't matter, right? The only reason a lot of times we'll match them is so that they look exactly the same. But it's totally like a team preference. If you prefer to use the Redux toolkit side style, you're more than welcome to, if you prefer to have them just match what you see in the code.

[00:03:30]
We'll see the developer tools later, I personally, I like the Redux toolkit style. It's just hard to do in a just regular Redux application. And then also when I'm using the developer tools later, I like whatever I see in the development tools to match whatever I'm using in my code, right?

[00:03:45]
It gets a little crazy when you're using increment all capital letters because you have to. And then you have it looking different when you look at the tools and things flow through. Totally matter of preference. You can use whatever you want.
>> What's a good reason not to use Redux Toolkit?

[00:03:58]
>> So there's a few reasons, right? One is, if you have an existing code base that is more than a year or two old, right, there's a definite whether or not it's time to refactor, right? Which is for a library's that's been around for five or six years, to be clear, most of future code bases that we write may or may not use Redux Toolkit.

[00:04:21]
But all the previous ones that predate it definitely don't. The other factor is like Redux Toolkit, the advantage to it is also the disadvantage, right? Advantage, is it takes a bunch of common patterns and abstractions and papers over them so you don't have to think about them. But that's like most abstractions which is, if you are doing particularly complicated things, right?

[00:04:45]
You might spend more time fighting the conventions that enhance and make your life easier than you would kind of just dropping down one level. Good abstractions should help you for most cases, but usually they have to give you an exit hatch, right? In the cases where they're no longer working for whatever you're trying to do, right?

[00:05:03]
So things where an action might have been throughout many reducers about the application, right? Redux Toolkit allows for that, but you could find yourself spending more time trying to wire that all together than just dropping down a level and getting the kind of pieces that you can snap together yourself.

[00:05:19]
It really for a lot of things is a judgment call. We'll actually see that when we get to React Redux, there will be some decisions between hooks and the hierarchy component pattern where there isn't necessarily a right answer. It really depends on what your priorities are, and what the nature of the application are.

[00:05:37]
And I think it's about knowing that you have the choice and knowing what each one brings to the table. And then with you and your team, making the decision on how to move forward in that case.