Check out a free preview of the full Vuex for Intermediate Vue 2 Developers course

The "Vuex Modules" Lesson is part of the full, Vuex for Intermediate Vue 2 Developers course featured in this preview video. Here's what you'd learn in this lesson:

Divya explains that modules are a new concept in Vuex, and concludes that Vuex modules help separate state and functionality into smaller modules grouped by commonalities.


Transcript from the "Vuex Modules" Lesson

>> So Vuex Modules is a really neat concepts when we work with Vuex. [LAUGH] And specifically, what I mean by modules is Modularizing Vuex. So we already talked about isolating Vuex from Vue components, so that the components can use the store, and the store can live in isolation.

But what could be really useful is the ability to isolate the store, pieces of the store into different components. And I'll explain what I mean by that. But first, we'll go over the definition of what a Vuex Module is. And then, we'll talk about why that can be really useful.

A Vuex module allows you to subdivide the Vuex store. So each module has its own actions, state, mutations and getters, and this is really useful because it's the ability for you to isolate parts of the store. So again, you don't get into a place where code is really complicated, where for example, your store has not just inventory, also, as machines state, and so on.

So we'll look at that specific example of machine state and inventory state as well. So generally speaking, in the code that we've done, so far, we've had the machine, and inventory, and information regarding that, like the condition, as well as the stock all living in one single store.

This is fine because, again, this example is fairly paired down and fairly straightforward. So having everything in one store is fine. But in many applications, especially, if you work with giant, monolithic applications, or enterprise style applications, the store can get pretty clunky. Because there's various parts to it.

There might be a login component, a logout component. So a user instance there might be instance in terms of the specific data, or what exactly user preferences may be, and so on. And so because of that, you might want to isolate your store. In the example of what we have, we have a vending machine that has both machine state, as well as inventory state.

And so what is really useful is here's an example of what that looks like. So here's a screen cap of inventory with a machine state. So here, I have the machine state shows me the name of the machine, as well as when it was last serviced, and then, even has a button that allows me to service the machine, let's say.

And then, on the above half, you see inventory, which is just a list of the items within that machine. So these two things are sort of related. But they are separate. Because the name of the machine, let's say, is sort of independent of whether or not there is a bag of chips in inventory, or how many bags of chips that are in the inventory.

And so we might want to extrapolate those two to use a module. So far, when we looked at the store, we've had everything living all together in one. So let's look at state. States has inventory, and then, it might have various other pieces like when the machine was last serviced, here's just a new date, don't worry about that.

It's just an idea of date. And then, machine name, which is just the name of that specific machine. And so these pieces all live in one single state instance, so they're globally accessible to us. What we might want to do is extrapolate them so that the inventory is sort of independent from the machine name and last service, let's say.

So in order to do this, you could if you wanted to, create literally two Vue stores, so you could create one single store. You wouldn't call it the same thing, you wouldn't call it store, you would do like store one, and store two, maybe. But this is not very useful because, again, then you would have to have weird ways of naming things.

There might be clashes because you can't access it through this dollar store, and so on. So this is a bad way of doing things, do not do things this way. This is more just to show you, is this possible, it's not a good way of doing things at all.

Instead, a better way is to actually use modules, because Vuex allows you to do modules by default, so you don't have to do anything to hook those pieces up. In addition to state actions, getters, and mutations, you also have a modules attribute in store, which we didn't talk about until now.

And within modules, you can actually name a module, and then, define all the different attributes of a store within them. So you're essentially nesting your store within the modules in a store. So it's a bit, it looks complex. But it actually allows you to work with the store in a much more simpler fashion, cuz you know exactly the different pieces that work within it.

So for example, we have modules and then, within modules, we have inventory and machine, these are the names of the modules. So inventory is one, and machine is another. And then, within them, we have state. And obviously, what you need to define within the module namespace, or the module name is state actions, getters, and mutations.

That's where that lives, and in this case, we only talked about state, so I'm showing you state. So we have supply, which is specific to the inventory module, and then, we have the name of the machine, which is specific to the machine module itself. And so here we have extrapolated the various pieces of state in our Vue store, and added them as a module.

In the code, you're obviously accessing things in a modularized fashion, so for example, on the left, we see the store with modules. So you see the inventory module as well as the machine module. And on the right is where we see our component code. And in the component code, you might notice something different, which is, we're accessing the state in a slightly different way than we used to.

In the past, let's say we wanted to access the machine name. We could do this .dollar store.state.machine name, because that's accessing it on the global store. But because we're using modules, the specific data attribute and state attribute is not on the global space anymore, it's actually modularized. So in order to access machine name, you're now doing this .dollar store.state.machine.machine name.

And the specific module matches the name that you created in your module. So in my instance, I create a module called machine, so I'm doing this .dollarstore.state.module name. And so all of my states, when I create it this way, it's accessed through the module itself. So it's not on the global store, it's modularized.

And that's really nice, because it's fairly straightforward.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now