How to split Vuex Store into modules

If youve been following along in this series of Vue tutorials on how to make use of Vuex and Vue-Router in a Vue Project and how we can implement Firebase authentication in a Vue Project .

Even in such a simple project our Vuex Store and our Router files are growing starting to grow in size. Just imagine what those the size of those files would be in a larger more complex project. Pretty soon, we would end up with a file that is difficult to maintain, would require endless scrolling to find a section we would be interested in.

If you're working as part of a large team with a few developers and you're all working on different features of the application, but all sharing the same Vuex-Store file, you are going to run into continual merge conflict errors, which despite best efforts always seem to resort to issues being deployed to production.

Large code files also make unit testing a somewhat laborious process. Often with confusing unit tests being developed or in extreme cases large unit test files resembling the file under test.

What are Vuex-Store Modules

The solution is break down the Store.js into a multiple smaller module files. We are going to examine why the concept of code isolation is safer, cleaner and provides a clearer and easier understanding of program and data flow within an application.

The Vuex documentation, provides general information and it's quite easy to create name spaced modules, use the exposed helpers to connect the modules with created components and dynamically register them.

What this essentially means is that Vuex allows us to divide our store into modules. So in this example we are going to take our existing code which we have developed in Firebase authentication in a Vue Project split our Store.js file into modules.

Each module can contain its own state, getters, mutations, actions and even other nested modules. They are useful to separate areas of your app from other areas of your app.

After we've created the necessary modules, we register them in the store.

Vuex Modules can simply be thought of as Vuex stores within other Vuex stores.

We are also going to examine some additional file organisation techniques and strategies we can use in order to introduce concepts from strongly typed languages into JavaScript code in order to help reduce errors introduced by over use of Magic Strings and numbers.

Why Use Vuex-Store Modules

There are a number of reasons why you would want to make use of Vuex-Store modules besides the previous mentions of organisation, clean code, test-ability and maintainability. These are great reasons and definitely are always my first considerations. However, probably the best reason is code reuse.

If we take our example we're going to be dealing with in this tutorial Authentication using Firebase this is going to be a recurring theme in any project. You also probably don't want to re-implement this pattern and strategy from scratch every time you start a new project you will also obviously have a similar implementation using AWS Amplify.

Taking the opportunity to Modularize code enables you to reuse modules across several projects. So implement an approach in one project and it works you probably want to re-use across all your projects.

This further promotes collaboration across teams and projects and really promotes refining and improving your code bases in general.

How to create Vuex Modules

In order to start this process we will need to create a new folder in our source code directory which we will call store

mkdir src/store

We then create a blank index.js file in store directory and each of the subsequent child directories we created.

touch src/store/index.js

We are going to sightly refactor code for the project. Our existing store.js we developed in How to Use Vuex and Vue-Router in a Vue.JS Project .

We are now going to simplify in order to introduce Modularization, we will add the following code to index.js. You will notice we will still be making use of Vuex-Persist and LocalForage, these may be project specific settings that you will want to use, so we will set this up within our project specific Vuex Store configuration.

import Vue from 'vue'
import Vuex from 'vuex'
import VuexPersist from 'vuex-persist';
import localForage from 'localforage';

Vue.use(Vuex);

const vuexStorage = new VuexPersist({
    key: process.env.VUE_APP_STORAGE_KEY,
    storage: localForage,
});

export default new Vuex.Store({
    plugins: [vuexStorage.plugin]
});

We have drastically simplified this file now and any developer who opens this can quickly at a glance get to understand what the code conveys.

We are now ready to start developing our Authentication Module which in this example is going to focused around making use of Firebase Authentication.

We will create useful folder structure to help organise our code. We're going to try think of a good name for our folder.

Choosing good names takes time but saves more than it takes
Robert C. Martin - Clean Code

# Create the folder
mkdir src/store/auth

# Create the default file
touch src/store/auth/index.js

You will notice in both instances I created an empty JavaScript file and have named index.js . I have done this for a very explicit reason and that is to make use of syntactic sugar exposed by Webpack and other file bundlers in the JavaScript ecosystem and it has one of the most subtle but useful benefits of this organization structure. In ES6,

Having an index.js file in a folder lets you perform an import from the folder implicitly without specifying the index.js in the import statement.

We are also going to take this opportunity to to implement an approach in order to reduce the use of Magic Strings in our code. We are going to implement a types file which will contain constants we will use to define action and mutation names.

touch src/store/auth/types.js

We will add our common names for our actions and mutations in the file as constants.

export const Action = {
    LOGIN: "LOGIN",
    LOGOUT: "LOGOUT",
    REGISTER: "REGISTER"
};
export const Mutation = {
    LOGIN: "LOGIN",
    LOGOUT: "LOGOUT"
};

We can now add some additional folders to separate our sections of store. The approach we are taking is just one of several possible approaches. I have chosen to take this approach as it suitable for the needs of this module and for the future growth of the additional complexity we will introduce at the later stage.

# create directories
mkdir src/store/auth/actions
mkdir src/store/auth/getters
mkdir src/store/auth/mutations
mkdir src/store/auth/state

# Add index files
touch src/store/auth/actions/index.js
touch src/store/auth/mutations/index.js
touch src/store/auth/getters/index.js
touch src/store/auth/state/index.js

We can now refactor our store and move the code to the appropriate files. Lets move our actions first. Add the following code to src/store/auth/actions/index.js

The code almost remains the same just with some notable exceptions, we import our types file with Action and Mutation defined, then in the highlighted line we make use of the these labels using the [] notation refering to the action name.

You will notice we also make use of String Interpolation to to refer to the Mutation, using the back tick </code> and referring to our constants in our mutation commits i.e. <code>${[Mutation.LOGIN]}</code>    Lets add code to our <code>src/store/auth/getters/index.js</code>    Then our touch <code>src/store/auth/mutations/index.js</code>    and finally <code>src/store/auth/state/index.js</code>    We can add the following code to our <code>src/store/auth/index.js</code>    Our new modularized store is ready for use. However, we just need to make a few minor edits to our Views to incorporate our changes.   We will only take a look at our Login and Logout functionality but the principles now apply wherever we make use of the Authentication store in our application.   We now import our types file and use string interpolation to refer to action we want to call. This reduces making use of Magic Strings in our code. i.e <code> this.$store.dispatch(${Action.LOGIN}, {email: this.email, password: this.password})</code>   You will notice I make use of the <a rel="noreferrer noopener" aria-label="Material Design Component Framework (opens in a new tab)" href="https://threenine.co.uk/material-component-framework-vue/" target="_blank">Material Design Component Framework</a> to assist in developing the Presentation views of my code. For interest, my framework of choice for this is <a rel="noreferrer noopener" href="https://mdbootstrap.com/products/vue-ui-kit/?utm_ref_id=47167" target="_blank">MDB Vue : A Material Design Component for Vue Pro</a>

`Summary`





We have broken our store down to make use of a Modular approach instead of creating one large un-maintainable file. 



The approach outlined is just one of the approaches you can use, however it is my preferred approach if you are going to work on large complex projects, helping to isolate your store logic to specific modules.





                          About
 Latest Posts
  
 
Gary Woodfine
Technical Director at threenine.co.uk
Gary is Technical Director at threenine.co.uk, an independent software vendor specialising in IoT, Field Service and associated managed services,enabling customers to be efficient, productive, secure and scale-able.
 
 
Latest posts by Gary Woodfine (see all)
									What is this Directory.Packages.props file all about? - January 25, 2024				
									How to add Tailwind CSS to Blazor website - November 20, 2023				
									How to deploy a Blazor site to Netlify - November 17, 2023