SoFunction
Updated on 2025-04-03

10 Best Practices for Establishing and Maintaining Large Projects

This is my best practice when developing when using a large code base for Vue projects. These tips will help you develop more efficient code that is easier to maintain and share.

During my freelancing career this year, I had the opportunity to work on some large Vue applications. The projects I'm talking about have over 12 Vuex storage, a large number of components (sometimes hundreds) and a lot of views (pages). Actually, this was a very meaningful experience for me, as I found a lot of interesting patterns to make the code extensible. I also have to fix some wrong practices that lead to the famous spaghetti code puzzle

So today, I'm going to share with you 10 best practices that I recommend following if you're dealing with a lot of code bases.

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

One day, I just need to create a popup. At first glance, nothing really complicated is just including the title, description and some buttons. So what I have to do is take everything as attributes. Finally, I used three properties to customize the component, and an event is emitted when people click a button. Very simple! :sweat_smile:

However, as the project continues to evolve, the team asked us to display many other new content in it: form fields, different buttons (depending on which page it is displayed), cards, footers, and lists. I found that if I continue to use properties to keep this component expanding, it seems to be OK. But God, :weary: I was wrong! The component quickly becomes too complex to understand because it contains countless child components, uses too many properties and emits a large number of events. :volcano: I've gone through a horrible situation where when you make changes somewhere it ends up breaking something else on another page somehow. I made a Frankenstein monster instead of a maintainable component!

However, if I depend on slots from the beginning, it might be better. Finally, I refactored everything to provide this widget. Easy to maintain, faster to understand and more scalable!

<template>
  <div class="c-base-popup">
    <div v-if="$" class="c-base-popup__header">
      <slot name="header">
    </div>
    <div v-if="$" 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="$" class="c-base-popup__actions">
      <slot name="actions">
    </div>
    <div v-if="$" 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, based on 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 provides greater flexibility when displaying any components required internally.

As a rule of thumb, remember that when finally copying the properties of a child component in the parent component of the child component, you should start using the slot from this point.

2. Correctly organize your Vuex storage

Usually, new Developers start learningVuex, because they stumbled upon the following two problems:

  • They either need to access the data of a given component from another component that is actually too far apart in the tree structure, or
  • They need the data to continue to exist after the component is destroyed.

That's the first one they createdVuex Storage, understand modules and start organizing in applications.

The problem is that there is no single mode to follow when creating modules. But I highly recommend that you consider how to organize them. As far as I understand, most developers like to organize them by function.For example:

  • Verification code
  • blog
  • Inbox
  • set up

In my case, I find it easier to understand when organizing them based on 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 remember is that, in the long run, well organizedVuex Storage will make the team more productive. This will also make it easier for newcomers to revolve your ideas around your codebase when they join your team.

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

Most of my API calls (if not all) are in mineVuex operate(vuex actions) is carried out in. You may be wondering: Why is it better to call here?

Just because most of them are extracted I need to store (vuex storedata submitted in ). Additionally, they provide the encapsulation and reusability that I really like. There are a few other reasons why I do this:

  • If I need to get the homepage of an article in two different places (such as blog and homepage), I can call the appropriate scheduler with the correct parameters. The data will be fetched, committed and returned, with no duplicate code except for the scheduler call.
  • If I need to create some logic to avoid extracting it when extracting the first page, it can be done in one place. In addition to reducing the load on the server, I have confidence that it can be used anywhere.
  • I can track most of my Mixpanel events in these actions (vuex actions), making the analytical code base really easy to maintain. I do have some applications where all Mixpanel calls are made separately in the operation. When I don't have to know what to track and what not track and when to send it, :joy: How much joy will work this way bring me.

Translator's note:Mixpanel It is a data tracking and analysis company that allows developers to track various user behaviors, such as the number of pages the user browses.iPhone Application analysis,Facebook Application interaction status, and Email analysis. similarFirebaseThe same point analysis tool.

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

When you only need to accessstate/getterOr call inside the componentaction/mutationWhen , it is usually not necessary to create multiple computed properties or methods. usemapState ， mapGetters ， mapMutations andmapActions It can help you shorten your code, simplify the complexity through grouping, and grasp the overall situation from one place in your storage module.

// 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 => 
    })
  },
  methods: {
    // Accessing actions
    ...mapActions("my_module", ["myAction"]),
    // Accessing mutations
    ...mapMutations("my_module", ["myMutation"])
  }
};

VuexAll the information you need on these handy helpers is provided in the official documentation.

5. Use API Factory

I usually like to create one this.$api Assistant that can be called anywhere to get the API endpoint. In the root of the project, I have an API folder with all classes (see one of them below).

api
├── 
├── 
└──

Each node groups all endpoints of its category. This is meNuxt The way this pattern is initialized in an application using plugins (this is very similar to the process in a standard Vue application).

// PROJECT: API
import Auth from "@/api/auth";
import Teams from "@/api/teams";
import Notifications from "@/api/notifications";
export default (context, inject) => {
  if () {
    const token = ("token");
    // Set token when defined
    if (token) {
      context.$(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 operations, as follows:

export default {
  methods: {
    onSubmit() {
      try {
        this.$(, );
      } catch (error) {
        (error);
      }
    }
  }
};

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

Your project may have some global configuration variables defined in some files:

config
├── 
└──

I like to pass this.$config Assistant accesses them quickly, especially when I'm in a template.As always, extending Vue objects is very easy:

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

7. Follow a convention to write submission comments

As the project develops, you will need to regularly browse the component's submission history. If your team does not follow the same convention to write their submission instructions, it will be difficult to understand the behavior of each team member.

I always use and recommendAngular commitMessage guidelines. In every project I work on, I follow it and in many cases other team members quickly find it better to follow it too.

Following these guidelines results in more readable messages, making it easier to track commits when viewing 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 "

Look at theirREADMEDocuments for more conventions.

8. Always freeze the package version when the project is produced

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

To avoid shattering the entire project by waking up in the middle of the night by one of your dependencies, locking the version of all packages will reduce your morning work stress. :innocent:

Its meaning is very simple:Avoid using versions starting 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 lot of data, you may have noticed that the page renders very quickly. To resolve this issue, you can usevue-virtual-scoller。

npm install vue-virtual-scroller

It will render only 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 very smooth

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

10. Track the size of third-party packages

When many people work on the same project, if no one pays attention to them, the number of installed packages will increase rapidly, which is incredible. To avoid slowing your application (especially when mobile networks get slower), IVisual Studio CodeImport fee packages are used in it. This way, I can see directly from the editor how big the imported module library is, and can see what goes wrong when the imported module library is too large.

For example, in a recent project, the entire lodash library was imported (about 24kB after compression). The problem is that only the project usescloneDeep A method. After identifying this issue in Import Fee Package, we resolved it by:

npm remove lodash
npm install

Then you can import the clonedeep function where you need it:

import cloneDeep from ""; 
ofJavaScript

For further optimization, you can also useWebpack Bundle AnalyzerPackages are visualized through interactive scalable tree mapsWebpackThe size of the output file.

This is the end of this article about 10 best practices for building and maintaining large-scale projects. For more related project practice content, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!