Structuring A Massive Vuex Store

Hello, Vue.js London. I'm so glad for speaking here today. My name is Doma Gawidowic. Feel free to call me Dom because it's just way easier to pronounce. I work at Orbital Witness, a cool London tech startup somewhere between prop tech and legal tech, and I also live in London.

Today, I will be talking about structuring a massive, massive UX store. How to create an architecture that is scalable, flexible, and maintainable. Currently, we're using this architecture at Orbital Witness. We have zero problems with it. Let's dive in.

I will start with an example of a simple store. I will be expanding that store in every step and presenting you the challenges we need to solve and, obviously, solve it. We're gonna start with the simplest store possible. We're using create store from UX, and we're creating an empty store with empty state actions, mutations, and getters. I won't be explaining those. I assume that you already know that. I will focus on how to create a store and make it scalable, make it appropriate for usage in huge apps.

Let's add some properties here now. Usually in your huge apps, you're going to have thousands of different properties. Right now, only two of them are enough, username and organization name, and obviously some mutations to set both. What would happen if this file had thousands of properties? You can imagine, just like adding, adding, adding things here, and file will just become bigger and bigger and bigger. We don't want to do that. If we're going to do that, why don't we just keep all of our code in app.vue and forget about components? Jokes aside.

Let's see how can we fix this problem. To do so, we're gonna use a native UX feature called modules. Modules allow us to separate the concerns, to isolate different parts of the store, and to make mini stores within our massive, massive store. Take a look at user module, for example, here, we took everything connected to the user, so name and it's mutation to set that name. We are also passing actions and getters as an empty object because we don't have any right now. And what is really important here is that namespaced attribute which is set to true. Namespaced attribute allows us to register those properties for that mini store to local namespace, to local namespace of that module.

In that way, we can access those properties from any other module, which is good because namespace set to true prevents us from accidentally accessing some of the local modules properties. You might think of that as a limitation, right? Because sometimes you actually need to trigger some methods from the different modules, but you can't right now. Well, you can, but you need to have an intent to do it. So it is possible, but you just need to have an intent. But this is definitely good because we're preventing those accidental triggering. You can have same state properties, with the same name or mutations, actions, gathers with the same name, namespace set to true allows us that. And its default value is false.

In that way, all properties will be registered at the global namespace. Maybe you want to do that, but just be careful about it. Organization module is literally the same. So we took everything connected to organization, set namespace to true, and we're exporting default that object. If we take a look at index.js file, the things have changed a bit. So now we have user module and organization module. We need to import them. And then we need to pass them to modules object. We're mapping those important modules to a certain name. Right now it's user and organization. This is cool. So we've already separated our store in different modules. They are isolated. We can't access them by an accident, but there's still something we need to solve.

Let's see, how can we use these mutations right now? We as developers hate hard-coded strings. They're not maintainable. They're not scalable. If you need to change something in your project, you literally have to search the whole code base and replace it. You can do search replace over the whole code base and then make crazy mess. It's a recipe for bugs. Don't use hard-coded strings. Right now, we don't have any other options because we can trigger mutations in two ways. First one, directly accessing the store object and triggering, for example, action send mutations.

You would trigger commit and dispatch methods from that store object. You still need to pass hard-coded strings there. But I definitely don't recommend doing it that way. We have UX helpers, map mutations, map getters, map actions and maps state for that.

Why is that good? Well, imagine massive apps with many, many, many components and files and massive, massive store. If you're accessing that store, that global store, which controls your for application directly, it's just not clear. You're gonna have thousands and tens of thousands or even more references directly to this.store object and it will just all be a mess. With map mutations and all the other helpers, you literally see, oh, this component, my random component is using these parts of the store and it's clear, you have it all in one place.

You still have to use hardcoded strings right now, but we're gonna solve that. Take a look at map mutations. Because our modules are namespaced, we need to pass module name as a first argument. That's why we in the first scenario, past user, second argument is an array of mutations. So just one string here, set username. Let's solve this. To do so, we need to extract the strings. It's pretty, pretty simple. You need to do three things. Create a const, export it, and then set that const value as a mutation name. And that's it. The same thing in the organization model, creating a const, exporting it so that you can import it in the other files and setting it as a mutation name. That's it for the modules. The other thing we need to add is module object, which will just be a list of all of our module's names. Then we need to import that object to our index.js file and just use values from that object rather than hard-coded strings for user and organization. Pretty simple, right? Let's see how we improved our usage by doing this. So, if we take a look at our random component, now we obviously need to import setUsername, setOrganizationName and module object. But right now in mapMutations, we're not passing hard-coded strings anymore. We're passing a module name and the second argument, we're not passing an array anymore, rather an object where we map a mutation name to a name we want to use in our component. So right now it's setOrganizationName and setUsername, you can set it to any way you want. It's completely up to you. Good.

So RSTAR is split into modules, right now. We have those mini stores. Their usage is so clear. Not only that we have mapMutations and possibly all the other helpers like mega-headers, mapactions, we also need to import those methods to use them.

So immediately when you open your component at the top of the file, we will see, okay, I use setUserName here and setOrganizationName here. And it's so clear. Oh, this component uses these parts of the store. It's really important when your app scales that you have that clear, clear picture rather than just accessing store object directly. And because of namespace set to True, RSTAR is isolated too. We don't have hard-coded strings. Yeah, best thing.

But there's still one problem we need to solve. Even though our app is split into modules now, those modules can be pretty, pretty big. And we need to somehow solve that and split them even more. To do so, we need to take a look at our current folder structure first. At the top we have root store folder, then within it we have index.js, modules.js, organization module.js, and user module.js. This is pretty cool for small apps, mid-sized apps, but it's not good for massive apps. That's why we need to refactor this structure.

This is our desired structure. Store is the same, so that root folder is at root, index.js, and module.js inside. But right now we've added another folder called modules. And within that folder, we're gonna have multiple folders with the separate modules. So right now we have organization and user. Within organization we have actions, getters, index, mutations and types. And within the user, we have the same things. I just didn't want to expand it because it will look bad. Let's take a look now at the details of these files. How can we do that? So the title says splitting the modules. That's basically what we need to do right now. We need to grab certain parts of our modules and just create separate files for them, extra default to those objects and we're good to go.

First we have types.js file. You remember those hard coded strings. So this types.js, basically it's a list of all costs, actions, mutations and getters. Everything we have and use in this module. It serves as a kind of a documentation as well. You can look here, oh okay, this module is using these methods. It's pretty reasonable, pretty clear. It's not clotted with any logic, just const here. So yeah, this is a nice sort of a documentation.

Then we have mutations. We obviously need to import consts from types and set mutation names to those const values. Usually you're gonna have multiple mutations here. Right now we have only a single one and then you need to export default that object. With actions, currently we don't have any actions. That's why we are exporting default, an empty object. That is possible to happen for some new modules. I highly recommend exporting default and empty object rather than not having anything at all here or not having a file at all, just so you can be consistent. And then when you add something inside, you already have that boilerplate for it. Everything with actions is the same as with mutations, the same goes on for gathers. You, right now, we're just exporting an empty object but the process is the same as with mutations and actions.

Finally, we have our index.js. That's not that index.js in root store folder. That's index.js within organization folder, within our module. Here, we need to import actions, mutations and getters. Then we need to create a state object. You might think, oh, we can maybe create a separate file from state and import it too. And that's true. You can do that. You don't have to do that. We don't do it because state object doesn't have any logic connected to it.

We love that every time we open an index.js file that we can see everything there. It's just what we do. You can create a separate file for it. You don't have to, it's completely up to you.

I definitely recommend creating separate files for actions, getters and mutations because there is a lot of logic behind those methods. We trust those logic, right? And that's why we don't want to look at it. We just want to import it and have a clean look of the state.

Finally, we need to export default.object by setting, of course, namespace to true, passing state, mutations, actions and getters. The process is the same for all modules. So I won't repeat the same thing for user module right now, because it's literally the same.

What we need to do now is update our root store. To do so, we need to import user module, import organization module, and import our module object with all the names. Then, we're gonna declare global state, global actions, global mutations, and global getters. Be careful with them because they are accessible at the global namespace. That's the place where they will be registered. Right now, they're empty, but the process is the same as with the ones which are namespaced, the process for creating them.

Then, we need to create modules folder. We're gonna map user module to username and organization module to organization name we're getting from the module const. Finally, we need to use create store from Vuex. We need to export default let object with state, actions, mutations, getters, global ones, and modules. And that's it. We have it now. We have that clean, scalable, and flexible architecture of the store for your massive app.

Let's take a look at it. At the top, we have index.js file, our root store. That root store has its own global state actions, mutations, and getters. But from the second layer, that root store imports all the different modules you have. Right now, we have only organization and user, but you're going to have much more, trust me. And then all those different kinds of modules from the second layer, import their own isolated actions, getters, mutations, state from the third layer. Right now at Orbital Witness, we don't have any problems with this architecture.

These three layers are enough, but if you're a pro player, then you can actually create a fourth layer. So you can split, for example, your mutations into different clusters. You can separate them by concerns and obviously important to some index file and then import it to the third layer. And that's something for massive, massive apps. I would say, we don't need it right now. We could do it, but we're not doing it right now.

If you have something like massive, massive, massive app, then you can create a fifth layer. And this process, you can dig as deep as you want. You can have as many layers as you want. This architecture supports massive apps, the massivest apps you can see. And that's everything I wanted to say here.

Thank you all for your attention. It was so nice speaking here. Feel free to drop any questions. If you don't have anything on your mind right now, you can find my information on the conferences website under speakers. You have my email there. We can connect on Twitter. Also check out my GitHub profile because this code is publicly available there. So you can use it as a boilerplate for your new app. Or if you want to refactor your current store, you can take a look at these practices. You don't need to refactor the whole store at once. So take your time, take days, weeks, months, whatever you need. And yeah, you can do it partially. That's everything for me. Thanks a lot.