Structuring A Massive Vuex Store

Rate this content
Bookmark

Dive deeply into the architecture of our massive Vuex store. This solution will always be easy to scale, read, and maintain no matter how huge your app is.

21 min
20 Oct, 2021

AI Generated Video Summary

The Talk discusses the process of structuring a massive UX store using modules in Vue.js. It covers topics such as namespaces, triggering mutations, and improving store usage with map mutations. The importance of refactoring the folder structure and using separate files for actions, getters, and mutations is highlighted. The Talk concludes by mentioning the possibility of adding additional layers for splitting mutations and providing contact information for further inquiries.

1. Introduction to Structuring a Massive UX Store

Short description:

Hello, Vue.js London. Today, I will be talking about structuring a massive, massive UX store. Let's start with an example of a simple store and expand it step by step to solve the challenges of scalability and maintainability. We'll use modules to separate concerns and create mini stores within the main 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.

2. Using Namespaces and Triggering Mutations

Short description:

In this part, we learn about accessing properties from any module, preventing accidental access, using namespaces, and exporting modules. We also discuss the importance of avoiding hard-coded strings and the two ways to trigger mutations.

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.

3. Improving Store Usage with Map Mutations

Short description:

You would trigger commit and dispatch methods from the store object. We have UX helpers, map mutations, map getters, map actions, and map state. With map mutations and other helpers, you see which parts of the store your component is using. To solve the hardcoded strings issue, use map mutations. Create a const, export it, and set it as the mutation name. Do the same for the organization model. Add a module object with all the module names. Import the object to index.js and use its values instead of hardcoded strings. This improves our usage.

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.

4. Splitting Modules and Refactoring Folder Structure

Short description:

RSTAR is split into modules, and their usage is clear. We import methods like mapMutations and setUserName and setOrganizationName. Namespace isolation prevents hard-coded strings. However, the modules can still be large, so we need to refactor the folder structure. The desired structure includes a 'modules' folder with separate folders for organization and user modules. Each module has actions, getters, index, mutations, and types files.

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.

5. Types.js, Mutations, Actions, and Index.js

Short description:

The types.js file serves as a documentation for all the costs, actions, mutations, and getters used in the module. It provides a clear overview of the methods used. Mutations and actions are imported and exported as default objects. The same process applies to getters. In the index.js file within the organization folder, actions, mutations, and getters are imported. A state object is created without any logic connected to it.

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.

6. Updating the Root Store and Creating Modules

Short description:

We recommend creating separate files for actions, getters, and mutations to keep the logic clean and import them for a clean look at the state. Update the root store by importing the user and organization modules, declaring global state, actions, mutations, and getters, and creating a modules folder. Use create store from Vuex to export the clean, scalable, and flexible architecture of the store for your massive app.

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.

7. Additional Layers and Conclusion

Short description:

If you're a pro player, you can create a fourth layer for splitting mutations into different clusters. This architecture supports massive apps. Thank you all for your attention. Feel free to drop any questions. Find my information on the conference website. Check out my GitHub profile for the code.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
Vue.js London Live 2021Vue.js London Live 2021
20 min
One Year Into Vue 3
Vue 3 may still sound new to many users, but it's actually been released for over a year already. How did Vue 3 evolve during this period? Why did it take so long for the ecosystem to catch up? What did we learn from this process? What's coming next? We will discuss these questions in this talk!
Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Rust is a new language for writing high-performance code, that can be compiled to WebAssembly, and run within the browser. In this talk you will be taken through how you can integrate Rust, within a Vue application, in a way that's painless and easy. With examples on how to interact with Rust from JavaScript, and some of the gotchas to be aware of.
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.

Workshops on related topic

Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Workshop
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.
Vue.js London 2023Vue.js London 2023
137 min
TresJS create 3D experiences declaratively with Vue Components
Workshop
- Intro 3D - Intro WebGL- ThreeJS- Why TresJS- Installation or Stackblitz setup - Core Basics- Setting up the Canvas- Scene- Camera- Adding an object- Geometries- Arguments- Props- Slots- The Loop- UseRenderLoop composable- Before and After rendering callbacks- Basic Animations- Materials- Basic Material- Normal Material- Toon Material- Lambert Material- Standard and Physical Material- Metalness, roughness - Lights- AmbientLight- DirectionalLight- PointLights- Shadows- Textures- Loading textures with useTextures- Tips and tricks- Misc- Orbit Controls- Loading models with Cientos- Debugging your scene- Performance
Vue.js London Live 2021Vue.js London Live 2021
176 min
Building Vue forms with VeeValidate
Workshop
In this workshop, you will learn how to use vee-validate to handle form validation, manage form values and handle submissions effectively. We will start from the basics with a simple login form all the way to using the composition API and building repeatable and multistep forms.

Table of contents:
- Introduction to vee-validate
- Building a basic form with vee-validate components
- Handling validation and form submissions
- Building validatable input components with the composition API
- Field Arrays and repeatable inputs
- Building a multistep form
Prerequisites:
VSCode setup and an empty Vite + Vue project.
Vue.js London Live 2021Vue.js London Live 2021
116 min
Building full-stack GraphQL applications with Hasura and Vue 3
Workshop
The frontend ecosystem moves at a breakneck pace. This workshop is intended to equip participants with an understanding of the state of the Vue 3 + GraphQL ecosystem, exploring that ecosystem – hands on, and through the lens of full-stack application development.

Table of contents
- Participants will use Hasura to build out a realtime GraphQL API backed Postgres. Together we'll walk through consuming it from a frontend and making the front-end reactive, subscribed to data changes.
- Additionally, we will look at commonly-used tools in the Vue GraphQL stack (such as Apollo Client and Urql), discuss some lesser-known alternatives, and touch on problems frequently encountered when starting out.
- Multiple patterns for managing stateful data and their tradeoffs will be outlined during the workshop, and a basic implementation for each pattern discussed will be shown.
Workshop level

NOTE: No prior experience with GraphQL is necessary, but may be helpful to aid understanding. The fundamentals will be covered.
Vue.js London Live 2021Vue.js London Live 2021
72 min
A Different Vue into Web Performance
Workshop
Solving your front-end performance problems can be hard, but identifying where you have performance problems in the first place can be even harder. In this workshop, Abhijeet Prasad, software engineer at Sentry.io, dives deep into UX research, browser performance APIs, and developer tools to help show you the reasons why your Vue applications may be slow. He'll help answer questions like, "What does it mean to have a fast website?" and "How do I know if my performance problem is really a problem?". By walking through different example apps, you'll be able to learn how to use and leverage core web vitals, navigation-timing APIs, and distributed tracing to better understand your performance problems.