10 Best Practices for Building and Maintaining Large-Scale Vue.js Projects

This is a best practice I developed while working on Vue projects with large code bases. These tips will help you develop more efficient code that is easier to maintain and share.

During my freelancing career this year, I've had the opportunity to work on some large-scale Vue applications. The projects I'm talking about have more than 12 Vuex stores, a large number of components (sometimes hundreds), and many views (pages). It was actually a very rewarding experience for me because I discovered a lot of interesting patterns to make the code extensible. I also had to fix some bad practices that led to the famous spaghetti code problem

So today, I’m going to share with you 10 best practices that I recommend you follow if you’re dealing with a large code base.

1. Use slots to make components easier to understand and more powerful

One day I just had to create a popup. At first glance, there’s nothing really complicated, just a title, description, and some buttons. So what I'm going to do is I'm going to treat everything as attributes. Finally, I used three properties to customize the component so that it emits an event when someone clicks the button. It's that easy! :sweat_smile:

However, as the project continued to grow, the team asked us to display a lot of other new things in it: form fields, different buttons (depending on which page it was shown on), cards, footers, and lists. I found that if I continued to use properties to make this component expand, it seemed to work. But God, :weary: I was wrong! The component quickly became too complex to comprehend because it contained countless subcomponents, used too many properties, and emitted a large number of events. :volcano: I've had that horrible situation where when you make a change somewhere it somehow ends up breaking something else on another page. I built a Frankenstein's monster instead of a maintainable component!

However, if I had relied on slots from the beginning, things might have been better. Finally, I refactored everything to provide this small component. Easier to maintain, quicker to understand, and much more scalable!

<template>
  <div class="c-base-popup">
    <div v-if="$slots.header" class="c-base-popup__header">
      <slot name="header">
    </div>
    <div v-if="$slots.subheader" class="c-base-popup__subheader">
      <slot name="subheader">
    </div>
    <div class="c-base-popup__body">
      <h1>{{ title }}</h1>
      <p v-if="description">{{ description }}</p>
    </div>
    <div v-if="$slots.actions" class="c-base-popup__actions">
      <slot name="actions">
    </div>
    <div v-if="$slots.footer" class="c-base-popup__footer">
      <slot name="footer">
    </div>
  </div>
</template>
<script> export default {
  props: {
    description:
      type: String,
      default: null
    },
    title:
      type: String,
      required: true
    }
  }
} </script> 

My point is that from experience, projects built by developers who know when to use slots do have a big impact on their future maintainability. This reduces the number of events emitted, makes the code easier to understand, and allows for more flexibility in displaying whatever components you want inside.

As a rule of thumb, remember that when you end up duplicating a child component's properties in its parent, you should use slots from that point on.

2. Organize your Vuex store correctly

Often, new Vue.js developers start learning Vuex because they stumble upon the following two problems:

• They either need to access data for a given component from another component that is physically too far away in the tree structure, or
• They need data to survive component destruction.

That’s when they create their first Vuex store, learn about modules, and start organizing them in their application.

The problem is that there is no single pattern to follow when creating modules. But I strongly recommend that you think about how you want to organize them. From what I understand, most developers prefer to organize them by functionality. For example:

• Verification Code
• blog
• Inbox
• settings

For my part, I find them easier to understand when they are organized according to the data model they extract from the API. For example:

• Number of users
• Team
• Message content
• Widgets
• article

Which one you choose is up to you. The only thing to keep in mind is that a well-organized Vuex store will make your team more productive in the long run. This will also make it easier for newcomers to wrap their minds around your codebase as soon as they join your team.

3. Use Vuex Actions to make API calls and submit data

Most, if not all, of my API calls are made in my Vuex vuex actions . You might be wondering: why is this call better?

Simply because most of them extract data which I need to submit in the storage ( vuex store ). Additionally, they provide encapsulation and reusability which I really like. I do this for a few other reasons:

• If I need to get the front page of an article in two different places (e.g. a blog and the front page), I can call the appropriate dispatcher with the correct parameters. The data will be fetched, submitted, and returned with no duplication of code other than the scheduler calls.
• If I need to create some logic to avoid fetching it when the first page is fetched, I can do it in one place. Besides reducing the load on my server, I'm confident it will work everywhere.
• I can track most of my Mixpanel events in these actions (vuex actions), making the analytics codebase really easy to maintain. I do have some applications where all Mixpanel calls are made individually in actions. :joy: How much joy it brings me to work this way when I don't have to keep track of what to track and what not to track and when to send.

Translation note: Mixpanel is a data tracking and analysis company that allows developers to track various user behaviors, such as the number of pages users browse, iPhone app analytics, Facebook app interactions, and email analytics. A point-of-use analysis tool similar to Firebase .

4. Use mapState, mapGetters, mapMutations and mapAction to simplify the code base

There is usually no need to create multiple computed properties or methods when you only need to access state/getter or call action/mutation inside a component. Using mapState , mapGetters , mapMutations and mapActions can help you shorten your code, simplify it by grouping it, and get the big picture from your storage module in one place.

// NPM
import { mapState, mapGetters, mapActions, mapMutations } from "vuex";
export default {
  computed: {
    // Accessing root properties
    ...mapState("my_module", ["property"]),
    // Accessing getters
    ...mapGetters("my_module", ["property"]),
    // Accessing non-root properties
    ...mapState("my_module", {
      property: state => state.object.nested.property
    })
  },
  methods: {
    // Accessing actions
    ...mapActions("my_module", ["myAction"]),
    // Accessing mutations
    ...mapMutations("my_module", ["myMutation"])
  }
}; 

All the information you need on these handy helpers is available in the official Vuex documentation.

5. Use API Factory

I usually like to create a this.$api helper that can be called from anywhere to get the API endpoint. At the root of the project I have an api folder which contains all the classes (see one of them below).

API
├── auth.js
├── notifications.js
└── teams.js 

Each node groups all endpoints of its category. This is how I initialize this pattern in a Nuxt app using a plugin (this is very similar to the process in a standard Vue app).

// PROJECT: API
import Auth from "@/api/auth";
import Teams from "@/api/teams";
import Notifications from "@/api/notifications";
export default (context, inject) => {
  if (process.client) {
    const token = localStorage.getItem("token");
    // Set token when defined
    if (token) {
      context.$axios.setToken(token, "Bearer");
    }
  }
  // Initialize API repositories
  const repositories = {
    auth: Auth(context.$axios),
    teams: Teams(context.$axios),
    notifications: Notifications(context.$axios)
  };
  inject("api", repositories);
}; 

export default $axios => ({
  forgotPassword(email) {
    return $axios.$post("/auth/password/forgot", { email });
  },
  login(email, password) {
    return $axios.$post("/auth/login", { email, password });
  },
  logout() {
    return $axios.$get("/auth/logout");
  },
  register(payload) {
    return $axios.$post("/auth/register", payload);
  }
}); 

Now, I can simply call them in my components or Vuex actions like this:

export default {
  methods: {
    onSubmit() {
      try {
        this.$api.auth.login(this.email, this.password);
      } catch (error) {
        console.error(error);
      }
    }
  }
}; 

6. Use $config to access your environment variables (especially useful in templates)

Your project probably has some global configuration variables defined in some file:

config
├── development.json
└── production.json 

I like to quickly access them via this.$config helper, especially when I'm in a template. As always, extending the Vue object is very easy:

// NPM
import Vue from "vue";
// PROJECT: COMMONS
import development from "@/config/development.json";
import production from "@/config/production.json";
if (process.env.NODE_ENV === "production") {
  Vue.prototype.$config = Object.freeze(production);
} else {
  Vue.prototype.$config = Object.freeze(development);
} 

7. Follow a convention for writing commit comments

As your project grows, you will want to regularly browse the commit history of your components. If your team doesn't follow the same conventions for writing their commit messages, it will be difficult to understand what each team member is doing.

I always use and recommend Angular commit message guidelines. I follow it in every project I work on, and in many cases other team members quickly figure out that it’s better to follow it too.

Following these guidelines results in more readable messages, making commits easier to track when reviewing the project history. In short, this is how it works:

git commit -am "<type>(<scope>): <subject>"
# Here are some samples
git commit -am "docs(changelog): update changelog to beta.5"
git commit -am "fix(release): need to depend on latest rxjs and zone.js" 

Take a look at their README file to learn more about the conventions.

8. Always freeze the version of the package when producing the project

I know... all packages should follow semantic versioning rules. But the reality is that some of them are not. :sweat_smile:

To avoid waking you up in the middle of the night because one of your dependencies has broken your entire project, locking down the versions of all your packages will make your mornings less stressful. :innocent:

What it means is simple: avoid using the version that starts with ^:

{
  "name": "my project",
  "version": "1.0.0",
  "private": true,
  "dependencies": {
    "axios": "0.19.0",
    "imagemin-mozjpeg": "8.0.0",
    "imagemin-pngquant": "8.0.0",
    "imagemin-svgo": "7.0.0",
    "nuxt": "2.8.1",
  },
  "devDependencies": {
    "autoprefixer": "9.6.1",
    "babel-eslint": "10.0.2",
    "eslint": "6.1.0",
    "eslint-friendly-formatter": "4.0.1",
    "eslint-loader": "2.2.1",
    "eslint-plugin-vue": "5.2.3"
  }
} 

9. Use Vue virtual scrollbar when displaying large amounts of data

When you need to display a lot of rows in a given page or need to loop through a large amount of data, you may have noticed that the page renders very quickly. To fix this problem, you can use vue-virtual-scoller .

npm install vue-virtual-scroller 

It will render only the visible items in the list and reuse components and DOM elements to make it as efficient as possible. It's really easy to use and glides on very smoothly

<template>
  <RecycleScroller
    class="scroller"
    :items="list"
    :item-size="32"
    key-field="id"
    v-slot="{ item }"
  >
    <div class="user">
      {{ item.name }}
    </div>
  </RecycleScroller>
</template> 

10. Track the size of third-party packages

When many people are working on the same project, the number of installed packages can quickly add up to an incredible amount if no one is keeping an eye on them. To avoid slowing down your app (especially on slow mobile networks), I use the import-expense package in Visual Studio Code . This way I can see how big my imported module library is right from the editor and can see what went wrong when my imported module library got too big.

For example, in a recent project, I imported the entire lodash library (about 24kB minified). The problem is that only one method, cloneDeep is used in the project. After identifying this issue in the import expense package, we resolved it in the following way:

npm remove lodash
npm install lodash.clonedeep 

Then you can import the clonedeep function where needed:

import cloneDeep from "lodash.clonedeep"; 
JavaScript

For further optimization, you can also use the Webpack Bundle Analyzer package to visualize the size of Webpack output files through an interactive, zoomable treemap.

This concludes this article on 10 best practices for building and maintaining large Vue.js projects. For more practical content on building and maintaining Vue.js projects, please search 123WORDPRESS.COM’s previous articles or continue browsing the related articles below. I hope everyone will support 123WORDPRESS.COM in the future!