All right, let's get back into it. So in the last episode, we learned together the basic principles of Vuex, and we started digging through the core concepts. For example, state. State is a single object that is reactive and can be accessed from any of our child components. We also learned about mutations. So we learned you never change the state directly. You instead use a mutation, and the mutation will be responsible for synchronously changing the state, as you can see here.

You instead use a mutation, and the mutation will be responsible for synchronously changing the state, as you can see here. But now I want to dig a bit more into getters and actions in this episode. So let's do getters. So as I understand it, getters are like typical computed properties, but you want to use them across multiple components. So you could throw it into a getter on your store, and then instantly it's accessible anywhere. At least that's my understanding of it. Let's see.

At least that's my understanding of it. Let's see. Yeah, you can see here, like, doneToDosCount. That's something you would traditionally use a computed property for. But again, I guess the Idea is if you put that in one component, but in other components you need that as well, you can just extract that out into a getter on the store. Is that about right? Yeah. If more than one component needs to make use of this, we have to either duplicate the function or extract it into a shared helper.

If more than one component needs to make use of this, we have to either duplicate the function or extract it into a shared helper. Instead Vuex allows us to define getter. Okay, so I'm assuming that's basically what it is. So why don't we try this out together? So we're sticking with this counter maybe a little bit longer, but very quickly we're going to have to use a different, better, more real-world example. So why don't we, let's do this computed, and then merge that in, and then we'll have, I'm going to do a computed property here, and then we'll extract it to a getter. So maybe, once again, what kind of computed property would we need for a counter?

going to do a computed property here, and then we'll extract it to a getter. So maybe, once again, what kind of computed property would we need for a counter? Let's just do something like the, this is dumb, the square root of the current count. So we could say square root would just be Math.sqrt. Is that right? I don't reach for this very often. Let's double check. Math.sqrt(9). Yeah, that's what we want. Okay, so that's, get the square root of this state.count.

Yeah, that's what we want. Okay, so that's, Math.sqrt(this.state.count). I think that's right. So then we could say, this is so dumb, the square root of this number. This is how I learned though. Keep it as simple as possible, because you're not interested in what you're building, you're just interested in the fundamentals and figuring out how things piece together. So we could say Math.sqrt. So let's give this a try. Cannot read property count of undefined.

So let's give this a try. Cannot read property count of undefined. Oh god, this store.state.count. Okay, give that a refresh. So let's run it. Yeah, so now when we get to nine, that's set to three. So this is working properly. So now we're going to imagine, folks, this squareRoot computed property is in hot demand. It needs to be used everywhere in the project. So instead, we'll get this into a getter.

It needs to be used everywhere in the project. So instead, we'll get this into a getter. So let's come back, and we can see, so on our store, we can add a getters object. So there, yeah, it's basically you just throw the computed property there, and it looks like it accepts the current state as an argument, and then you perform your filter or whatever you need to do. All right, so we're going to give this a shot. And then we'll go to the store, and yeah, I guess I can put it here. So what do we have? We have getters, and then paste it in.

So what do we have? We have getters, and then paste it in. Is that right? And then this accepts the state, right? So we could do, is that right? Let's come back. I think it's still going to fail. Property or method square, yeah. So we're going to have the exact same thing as we had before. So I'm assuming there's like a mapGetters, but just for now, could we delegate this dot

Three. Yeah. So now if I hit revert, yeah, notice how it went from three back to one. It should have gone from three back to two. And I assume, yeah, again, when it's asynchronous, Vuex can't properly track it and maintain that state before and after. Okay, so as I understand it, we need to use actions for this. So yeah, this is where it gets a little more complex. So actions are similar to mutations, the difference being that instead of mutating the state, actions commit mutations.

So actions are similar to mutations, the difference being that instead of mutating the state, actions commit mutations. Okay, so that means actions are for asynchronous operations that ultimately commit a mutation, and then the mutation will synchronously change the state. It's kind of sad that those have to be two different things. But immediately, to me, this seems confusing. So let's see, actions, increment. And what does this accept? It accepts a context. What's that?

This works good. And then if you ever want to create another terminal to do something else, you can do that there. Kind of cool. So now I have an action that performs something asynchronous, and it ultimately commits a mutation. But now from our counter, hmm, we're no longer mutating on click. So when you click on this, I no longer want to call this directly. I want to dispatch the action, and I think that is the term, dispatch. Yeah.

I want to dispatch the action, and I think that is the term, dispatch. Yeah. So instead of store.commit, if you're dispatching an action, you do store.dispatch. So hmm, let's come back. I'm assuming, once again, there's mapActions. Yeah, so I guess there's a helper like that for everything. So if we were to say mapActions, and then down here, mapActions increment. So now when the user clicks on the button, we will call increment on the store action. That will wait three seconds and then perform the commit. That will then hit this, and it will update the count.

So it is tracking everything properly. Okay, so that makes sense. So what else? Composing actions are often asynchronous. So how do we know when an action is done? store.dispatch can handle a promise. Okay, so if we return a promise from an action, okay. So if we want to, like, you can imagine an action doing some kind of AJAX call to an API, you could return a promise. So yeah, we could say, like, when you click on the counter, store.dispatch, increment.then,