State Management in Vuex

[00:00:00]
>> This is the second section of using Vuex. And we're gonna talk a little bit more in depth about the different pieces of Vuex. So, we touched a little bit about state, actions, and mutations which are really great. We didn't touch getters yet, but we will in this part.

[00:00:15]
We'll actually dive more into detail as to the different pieces of how you use them. And we're also gonna distinguish actions and mutations a little bit in this particular section. So, let's dive in. So, I like to call this, Responsibilities and state management systems because every piece has responsibilities.

[00:00:36]
State is where the centralized state exists. Actions are where you make the database calls, you fetch from API's. Mutations are where the state is actually mutated. And then, getters is sort of this sense of checking over the state or updating how the state renders on the front end.

[00:00:55]
So, we'll look at the diagram again, because I think it's useful to use as a way of cementing your understanding of UX. So again, we have our actions, we have our mutations, and we have our state and this flow of how things work. So, the component actually never changes the state directly.

[00:01:13]
It's the store that changes the state and specifically the mutation that changes the state. And we'll talk a little bit about that piece of like the dispatch of the action in the mutation itself because I think it's useful to understand those two pieces. The difference again is a bit kooky, but bear with me a little.

[00:01:32]
So, we have actions which are similar to mutations, but it commits those mutations. So, the action never actually changes the state directly. The mutation is where the state is changed. And I want you to look a little about and think about them as this asynchronous or synchronous. So, actions are asynchronous because you can't make those fetches.

[00:01:51]
You can't make those database calls and the mutations you can't do that because it is strictly synchronous. So, that's a really good way of thinking about the two in distinguishing how they work. So, we'll go back to our previous example of our stock counter except now we have this sort of in between state.

[00:02:07]
So, when you're dispensing previously, we just counted, we just sort of decrement and then incremented up to 40 to restock and dispense. But now, we have this concept of like is dispensing state. So, you see this transition state that happens and then it decrements. So that's sort of an extra layer of how the state is changing within an application.

[00:02:30]
So, you have an action that happens and then a mutation. And the reason I added the in between state is because I wanted to show you that asynchronous action that happens. So, just to return to this example, you might notice. I know you were very like enthralled with animation because I was, when you're dispensing notice that the counter doesn't go down and it only goes down after the animation finishes.

[00:02:55]
And so, this is sort of a way of modeling asynchronous actions because obviously, we're not me really fetching from an API or making an actual call to a database. But I wanted to show you that an action is asynchronous and mutation is synchronous. So, the action which is when you click the button, so you restock or you dispense.

[00:03:16]
It's happening asynchronously, because the idea is that you are doing something asynchronous. And so, I create a timeout, which is, again, modelling an asynchronous thing. And so, when you click Action, that action happens asynchronously and then once the action finishes, or once the async returns, then the mutation happens.

[00:03:36]
So, there are these two things and how they interact. So, it's no longer one-to-one or like it's no longer you ask an action to happen and automatically a mutation is committed. It's sort of async and then sync. So, let's look at how that looks like. And for the very first, as we go through this, we're going to start renaming things because I think it will help in terms of distinguishing.

[00:04:03]
So, actions and mutations previously were called restock. And that's mainly because there was not much difference besides the fact that one was actually touching state and one wasn't. But now, we're doing a bit more work here, so let's rename it. So, our action is called fetchFromInventory, because the idea here is that the action is actually checking inventory to be like, can I do this thing?

[00:04:24]
Does it exist in the inventory to restock? And then, the mutation is called stock items, which is the actual action of adding to the stock. And so, we'll rename those two things, just so it's a bit more clear that those two things are separate. And obviously, we also want to change what exactly is happening within the action and the mutation.

[00:04:47]
So, the action is fetching from the inventory and then the mutation is updating the supply. And of course, it's not much different in terms of the context.commit. So, it takes in a default parameter and then it commits the particular mutation that is not much different. But you might notice I created some comments which is make API call and on successful return, mutate, which is the asynchronous piece of what that will look like.

[00:05:14]
And we'll go into that in just a bit. But again, I just wanted to show you that the code isn't actually a lot different from what we looked at before in terms of what the component sees. So, from the component's perspective on line 30, you'll see that it should be this store, $store not store.

[00:05:31]
This store, $store.dispatch is still dispatching that particular action. So, that action is called fetchFromInventory. So, this store $store.dispatch will dispatch that particular action, so from the component perspective, nothing changed. It's just within the action, the mutation that we're making changes. So just for clarity, we're looking at action mutation, it's related but independent from the component for now.

[00:06:00]
So, what we'll look at is we'll look at specifically what we're doing. And for this, I'm gonna create, as I mentioned, a timeout like a set timeout, just to model an API call because I think it's easier than actually making an API call. It gives you sort of similar results.

[00:06:17]
And so for this, I'm going to fake out an API. So, I created a fake inventory, which has chips in it, and it has a stock of 40. So, that's just my fake inventory and then I created a method called pingInventory. You can call it fetch inventory, whatever you like.

[00:06:35]
PingInventories fine and then within it, it's just a promise. It returns a promise. And within that promise, there's a set timeout for three seconds or 3,000 milliseconds, and then it successfully resolves the particular inventory item. So again, in this instance, we're not doing anything besides just resolving what we expect to see and that is not the store itself.

[00:07:04]
That's just separate because I wanted to create a fake API, [LAUGH] that's sort of outside of the store. So, you might notice that it's not within the store at all. It's just sort of separate, and then we'll look at the actions itself. So, how does this relate to the specific action.

[00:07:17]
So, from line 22 to 25, that's when I'm actually calling this fake API. And of course, this fake API takes in a specific item, which in this case is chips. And so, I'm pinging an inventory for chips specifically, and then I am grabbing that thing, and then I'm passing it to the mutation.

[00:07:37]
So, there's a bit of things. There's a lot of things happening here, one is on line 22. We're actually pinging and asking for data from this specific API. So, pingInventory which is our API, and then on successful return, we're grabbing the item that's returned from the API. Because obviously, if you're fetching an API, you might want the return value, otherwise, why would you call an API.

[00:08:00]
And then, we want to pass that down to the mutation. And so, again, you will see the context.commit, which is again, the default parameter context was committing to the mutation. In this case, the mutation is called stockItems. But you'll see a difference here, which is previously we just did context.commit with the name of the mutation.

[00:08:22]
But here, we have a second parameter and the second parameter is the specific returned value from the API. So inventory.stock, which if you look at lines 1 to 6, which is what is the return value from our API. Inventory.stock is just 40, so it gives you a number.

[00:08:43]
And so, we care about that specific number because in this case, we don't really care about anything else. We just wanna stock it to a specific number. And so, what we'll do now is we will look at how that looks like from the mutation perspective. So, we looked at the action and how we're exactly calling an API and then passing that data down.

[00:09:03]
And then, next we'll look at the mutation itself.