Vuex for Intermediate Vue 2 Developers Static vs Dynamic Modules

[00:00:00]
>> We've talked a little bit about Vuex modules and how they can be really useful. How to namespace them to make sure that not just the state is modularized, but our actions, mutations, and getters are also equally modularized. But let's move on to talking a little bit further and deepening our knowledge of Vuex modules.

[00:00:19] So far, we've talked about static modules, and that might not make a lot of sense, but I think in this exercise, I'll show you what I mean by that. And I'll introduce this part by talking about it, with regards to static versus dynamic modules. And we'll think about those two as separate but sort of related and similar entities.

[00:00:42]
>> Within application that didn't probably definitely benefit from modules, within its store. Do you know is there any performance benefit for modularizing the store in this way? Does it help to process things through the store, if it isn't modules?
>> Yeah, I'm not 100% sure in terms of the performance implications of modules versus non-modules.

[00:01:10] But I can speak to one thing which is that if you use modules in a static fashion, you are instantiating and using your modules for across the application. So, like even though a component might not be using that particular module, there's still sort of a performance cost because anytime you are accessing the store that module namespaces available.

[00:01:38] And so, I think the question with regards to the performance implications will become clear in this section, if you can awesome cool. In the previous section we talked about Vuex modules and why that can be really useful specifically with namespacing and making sure that your state, actions, getters, and mutations are specific.

[00:02:00] So, it doesn't pollute the global Vuex namespace, that's really useful. But I think the next concept will be particularly interesting, especially if you're interested in performance and understanding how exactly modules can improve your applications. And I'll introduce this concept as a corollary. So static versus dynamic modules, and the difference between them will become clear in just a second.

[00:02:27] So, let's look at an example once this concept books loads, [LAUGH] of accessing a essentially like servicing a machine. So, we want to service a machine multiple times, and we want to access the number of times in which we service it. If this code samples doesn't work, I will load it locally.

[00:02:51] So, let's run the code that I have locally. So, I'm going to run some code just to show you what the example that I'm going to show is and looks like. [SOUND] Load, there we go, all right? So, here I have a counter. So it's just essentially showing me a number of machines.

[00:03:20] So it's a list of multiple machines and you might notice there's some text that says service x times. So, it shows you the number of times the machine has been serviced and in this particular case, I care to know this information. So, I wanna know how many times this service button has been clicked or how many times a machine has been serviced.

[00:03:40] So, let's just assume we're clicking it and you can notice that the counter, so the service number of times is increasing as you go. And if I look specifically in my Vuedev tools under Vuex, you will see that mutation happening which is completing the service request. And of course, the state is updating appropriately, so you'll notice I have to keep loading it updates every single time.

[00:04:08] So, this is fine and obviously, I'm using one single state object. So, we'll look at this, I modularized it, it's great. I even namespace it, so everything is accessible on the machine namespace. But the thing is, every time I use this specific store, it is copied across components.

[00:04:31] So, every component is using the same instance of the store. And this is sort of problematic because in the instance that I showed you, if I service. Let's say, if I service the machine named Bender, I don't want the machine called Farnsworth to update because again, this is specific to that machine itself.

[00:04:55] I don't want other machines to know that that happened, even though I'm using a similar store. Where is my code, yes. So essentially, I want to make sure that the store that I'm using is specific not only to the module, but specific to the component that I'm using.

[00:05:13] And so, this is sort of what I mean when I talk about static versus dynamic modules. Because a static module, which is what we've looked at so far, is registered on initialization across the component. So, whichever component accesses the store, it has access to that specific store and so it's not dynamically loaded.

[00:05:35] So, any component can access that store whenever the entire application initializes. The corollary to that is dynamic modules and dynamic modules, as the name is suggests, is registered on component initialization. So, only the component that uses it will initialize that store and if that component doesn't exist or if you're in another component, you cannot access that specific store.

[00:06:03] So again, we're gonna look back at the folder structure I talked about. In this case, I have modules and then I have within that my machine code and then I have my store.js or in my Vuex cli instance, it's store/index.js, but the example is the same. So, I can look at the two side by side just to see what we had before and then see what we can move towards to make it a bit better.

[00:06:30] So, we have our store.js file, import the specific modules as you can see on the top. That's what I want because the module code isn't here anymore, it's sort of separate. So, I import the specific module code. I added to my Vuex store like such, I can choose to create a constant and added or add it directly, whichever is better for you.

[00:06:52] It's namespaced as you can see here, so this is what the module looks like. This is what it looks like when you add it to the store. What I want to do is, I don't actually want to add the module in the store anymore, because the issue with adding a module in the store is that anytime anyone accesses that particular store, that module exists.

[00:07:15] And this is a problem because if a component is using or multiple components is using the same store, I don't want them to access this specific store. Because as you saw in the previous example, if I service one machine, it shouldn't service another machine. So, what we'll do is we'll pull away those pieces.

[00:07:31] We won't actually put the module code in the store anymore. So, we're not gonna use it statically so to speak, the module itself won't change. Nothing's changing there. The only thing that changes here is the store and how exactly you were accessing the module itself. So, this is where we're registering, we're moving the part in which we register the component of the module.

[00:07:56] We're moving it away from the main.js file into the actual component instance. So, this is what you see if you see the script component of your single file component in view and within that, we're going to register a module. So let's assume this as a component, let's say it's a vending machine item or one of those specific list items.

[00:08:22] And within that list item in the created portion, we don't really care about mounted because mounted is when something is visible versus created, which is on initialization of a component. So, that's if you want to know the difference between that, that's the difference. So, I created is useful because it's when the component first is initialized.

[00:08:43] I want to register that module. And so, in order to do this, I can call this.registerStoreModule with the moduleName and then pass in the specific module. And of course, this is not this part on the top which is the created part, is a method that I'm creating on my own.

[00:09:04] So below, you'll see a method called registerStoreModule, which is what I'm calling. It takes in a module name and the specific store module and then it does some things which is actually registering it. So, you might notice on the below part of the code this store.registerModule, so that is Vue specific.

[00:09:24] And that is something that I didn't write, it's accessible on the store. So, the Vue store has a method called registerModule and registerModule has the ability for you to take in a module name and a store module and register it, so to speak. If you think about it, this looks uncannily similar to the method that I just created call registerStoremodule.

[00:09:50] The difference here is that I'm checking that a specific module exists to begin with. So, I wanna make sure that the store exists, that there is a state, and so on. So, it's some extra code I added, but if you really wanted to, you could just do store.registerModule and that should work just fine.

[00:10:10] And of course, it's this.$store, I just renamed it to store because I don't like writing this $store. But the idea is the same, this.$store.registerModule, passing the module name, passing the store module and that will register a module in the component itself. So, with that I can now use the module as named.

[00:10:31] So, let's assume I have, state and actions that I'm accessing in a component, the state is called, let's say I'm accessing the time service. So, the number of times in which a machine was serviced, and then I also have an action call like service machine, which is the button click.

[00:10:47] So anytime you click it, it services or it increments the time service. So, I can access it with my Vuex helpers. I personally like Vuex helpers. So throughout this workshop, I might throw it in here and there because I prefer that. And so, here I'm using map state, which accesses the specific name of the module which is machine.

[00:11:09] And then, similarly with map actions, it specifically acts as a machine and then within that, I'm pulling apart or pulling out the state and the action that I'm using. So, I can actually create the specific module in the component and then use it quite easily without it having to live in the main.js file.