Vuex and Composition API Q&A

[00:00:00]
>> So because this is also, I know there's a lot in this topic, does anyone have any specific questions you'd like to address regarding sort of composition API and state management? So the question is whether or not I recommend using the map state instead of doing this dot store, dot state, for example.

[00:00:17]
In that regard, I would say that this mapping state is totally fine as far as keeping sort of user usability. Because I guess the only fear that you might have I think with map state would be named collisions. And so in that regard, you can actually V map some of those names so that let's say for example, you have a username in your vuex store.

[00:00:40]
But you also have a username inside of your component. In that case the map helpers is actually really cool because you can actually use an object syntax and renamed the property that it's not to. Basically you can define an alias for it. And so that way you still get the ergonomics of this dot.

[00:00:55]
I don't know call it store user name or whatever module it's associated to. That way you still get the ergonomics of having that shorthand. But at the same time you it's so explicit, you're avoiding the name collision while still leveraging the developer experience and benefit piece. So the question from what I heard is that in the event, we wanna dispatch some sort of or sorry if you wanna make a change in another module.

[00:01:21]
So okay, well let's go back to our example we have our shopping cart module. And we have our to do list module. That's the easiest way for us to remember. If shopping cart needs to make an update over to do lists like dispatch. So the question is whether or not to mutate it directly or dispatch actions, especially with this case.

[00:01:38]
We're talking about basically communicating between modules. I would recommend sticking with actions in this particular case. Because the moment you have an actual mutation linked together, it's like the provide inject example. You've created a fixed relationship where if in the future like over here in shopping list, we change either I don't know call it the mutation and how it works.

[00:02:02]
This can actually break what's going on over here. Whereas if you have an action you still need to update if things renamed and things. But you allow sort of a better, sort of a more declarative way of saying what you wanna do and then the implementation details can be taken care of later.

[00:02:17]
As opposed to doing the mutation directly from module to module. So, hopefully that helps answer your question. [LAUGH] So the statement made in the chat is that they enjoy the declarative nature or the more explicit nature of using this dot store, dot state, or dot dispatch, in order to be very explicit as far as what you're accessing rather than conflicting it with the component namespace, right?

[00:02:43]
So in this regard, it's related to the first question regarding weather map state or accessing the disk dollar store makes more sense. And so this is a perfect example of I think it's important to define what makes the most sense for your team long term. And so you're right if you feel that over time either the the local data instance is started getting muddled up with the map functions.

[00:03:05]
Absolutely. I agree that if you just keep it consistent, then you can go ahead and just always do the dispatch and do the state and getters directly with very little confusion. So, I just want you all to know basically with the tip to use it is that in the event that the ergonomics make more sense.

[00:03:23]
And so whether you can come up with a naming convention that maybe your team uses for when it's actually affecting the Vuex store for example. Then that way you can still leverage this dot whatever like the method or the getter state. But again, pick and choose what works best for your team and definitely don't take what I'm saying.

[00:03:41]
It's like a carpet Blanche, always do this kind of thing. So we have another great question here, which is regarding, well, if we have Vuex, right? And let's say, its underlying, it's already using composition, the API. Is there even any value in the composition using the composition API since we have Vuex.

[00:03:58]
And so for that, I would say absolutely. Similar to the object API and composition API discussion. The value of using Vuex with composition API is that Vuex is really that sort of single source of truth for that global store. And so the problem that people have run into is because over time, especially in view 2 people, relied on Vuex to house everything.

[00:04:20]
So if you had only two components, they needed to share something. That went into Vuex immediately. And especially you can imagine on an app that scales really quickly with a lot of state a lot of functionality API calls you can end up overloading your Vuex store. And so composition API is still beautiful in its ability to keep the simple thing shared.

[00:04:42]
So if it is a simple as a couple components needing one shared property that doesn't have a lot of dependency on everything else. Then I think in that case, composition API is still perfect for those scenarios, and that throwing it into Vuex is probably be overkill. On the other hand, if you have your functionality is fetching the API and doing all these things that have large impact across apps, then this is where the debug ability of the Vuex dev tools and those sort of things can be critical for those pieces.

[00:05:11]
So basically, I think the key principle here to keep in mind when determining when to use Vuex and when to use composition API is really determining how critical those functionality are as far as a global impact on your app. And then with that comes certainly basically the ability to debug and make things, and fixing faster.

[00:05:32]
So the other question we have here is regarding whether. A single action should only commit one mutation. Or I think the other one was whether a mutation should update multiple pieces of state. So I'm gonna answer this formula question, if I'm wrong, please, please clarify for me. So when it comes to actions, there really is no call it best practice, for how many mutations you should be committing.

[00:05:57]
After all, especially when you have things as complex as fetching an API and then breaking it out. A lot of times there are multiple things you're committing, because the API might give you one large response. Then you want to chunk out into different modules or different methods. There are definite reasons to commit more than once in an action and there's absolutely nothing wrong with that.

[00:06:16]
As far as mutating state, this is a more nuanced question, because the idea here is that, do you want a single mutation to update multiple pieces of state versus one? And so I think this is, call it a gut feeling. Unfortunately with this one, in the sense that think of it data-driven refactoring from.

[00:06:36]
I would probably start with atomic pieces only because atomic pieces can be composed into action. And so unless you're really sure about the architecture of this one mutation should update three pieces of state. And this is always the case and it should never change. Then there's an argument to impacting multiple pieces of state with a single mutation.

[00:06:59]
But I would say using composability and preventing your mutation from getting too tightly coupled, because you can imagine that if one mutation makes three changes, and then you use that mutation everywhere in your app. You basically can never refactor this without causing a lot of potential side effects.

[00:07:17]
Because basically, at various points in your app, you will be relying on three state changes. Whereas if we take again sort of composing, right, pieces together. If you do three individual mutations that change three different pieces of state, and then compose that into an action. Now in the future, you can break it up.

[00:07:38]
You can be, okay, yeah, we're using this action to commit three state changes, but then it's very easy to go. Do you know what? That three only I don't need that one I just need two and then I'll create one that does two for example.