Vue project code splitting solution

background

Since the previous database firewall product and database audit product used the same set of codes, as the differences in the functions of the two products became increasingly greater, the redundancy and coupling of the codes became increasingly higher. In order to facilitate later maintenance and adding new functions, the code structure was split based on the original project code.

Note: This split only splits the parts that can be split. Some modules, such as Rules and About Us, are not split. First, some modules are very simple and do not need to be split. Second, the original codes of some modules are too coupled and cannot be split. If they are to be split, a lot of effort will be needed to sort out the codes, and the backend will also need to cooperate with the split.

Purpose

Record this code splitting plan to help subsequent developers quickly familiarize themselves with the project structure.

Before split

Process Design

Before the project was split, the process of distinguishing between review and firewall functions was shown in the figure above.

When accessing the system, first load the entry file main.js, then load the login page login.vue. While loading the login page, get the product mode and save it to session.storage.platformType. Then the user logs in to the system and enters the specific page. This page includes both data audit and firewall functions. The specific function to be displayed is determined based on the value saved in session.storage.platformType.

Directory structure design

The directory structure before the project split is shown in the figure above.

This directory structure is the basic directory when initializing a Vue project. Based on the directory structure, it is basically impossible to tell that the project contains two different products, nor is it known which part of the files will be loaded in different product modes. The structure is not clear.

Problems

Through analysis, we can find that there are many problems with the current system process and directory structure, which can be summarized as follows:

1. The product mode is obtained when the login page is loaded. If the login page is loaded but the product mode has not been obtained or cannot be obtained, the product information displayed on the login page may be wrong.
2. Each time you enter a specific page, if it contains both data audit and firewall functions, you must re-determine whether the current function is data audit or firewall;
3. The directory structure is not clear, and it is unclear which modules are common modules, which are modules unique to the data audit, and which are modules unique to the firewall;
4. Poor maintainability and scalability. The code for the data review and the code for the firewall are mixed in one file. When modifying the code, you need to read it again from the beginning to know which code belongs to the data review and which code belongs to the firewall. If you want to add a function, you have to continue to add logical judgments, and the code becomes more and more bloated;
5. The business logic is confusing, and the same interface is used to communicate with the backend.
   

After split

Process Design

After the project is split, the process of distinguishing between the review and firewall functions is shown in the figure above.

When accessing the system, first load the entry file main.js, which contains the logic related to route interception. During route interception, if there is no product mode, you must first obtain the product mode, otherwise you will be intercepted and cannot enter the system. After obtaining the product mode, the corresponding login page, routing configuration, interface request, etc. will be registered according to the current product mode. After registration is completed, each visit to a specific page should be an independent module.

Directory structure design

The directory structure after the project is split is shown in the two figures above.

After the directory structure is split, you can clearly see the files separated from different products. Starting from the entry file, after routing interception, the specified login page will be loaded, and then the files required by the corresponding product will be merged into the public file. For example: http request, routing configuration, etc. As a result, the program will only load the files it needs.

Problems solved

After redesign, some problems existing in the current project have been solved:

1. Before loading the login page, the product mode must be obtained through routing interception before entering the system. The login page is loaded after the product mode is obtained, and there will be no problem of incorrect product information display;
2. Only when you enter the system for the first time or refresh the page, will the product mode be re-acquired and the files corresponding to the product mode be merged. The merged files are the split files, and there is no need to determine again in the file whether it is the data audit function or the firewall function.
3. The directory structure is clear, and firewall-related functional module files are placed in the views-fw folder.
4. It improves the maintainability and scalability of the project and reduces the coupling of the code. The code for data auditing and the code for the firewall have basically been separated. If you want to add a firewall function, you only need to add the file of the corresponding function module in the firewall-related folder.
5. The business logic is clear, and different interfaces are used for communication with the backend. The interfaces used by the public modules remain unchanged. The interfaces unique to the audit function have the "audit" prefix added to the URL, and the interfaces unique to the firewall have the "firewall" prefix added to the URL.
   

Key Code

/**
 * @Name: main.js
 * @Author: cqfeng
 * @Description: Project entry js file* @MainFunction: Import and register some global resources**/
//...code omitted...
// Route interception, using global navigation guard beforeEach
router.beforeEach(async (to, from, next) => {
 // If there is no product mode, get the product mode first if (!store.state.productMode.productMode) {
 await store.dispatch('productMode/SET_PRODUCT_MODE');
 }
//...code omitted...

/**
 * @Name: product-mode.js
 * @Author: cqfeng
 * @Description: Product mode related logic processing file* @MainFunction: Save the current product mode, configure product login page, http request and other resources according to different product modes**/
import Vue from 'vue';
import portService from '@/assets/js/service/http/http'; // axios requestimport router from '@/router/index'; // default routing configuration, dynamic routing configurationimport httpAAS from '@/assets/js/service/http/http-aas'; // http request unique to data auditimport httpFW from '@/assets/js/service/http/http-fw'; // http request unique to firewallimport globalConstant from '@/assets/js/const/global-constant'; // project global constantexport default {
 namespaced: true,
 state: {
 productMode: '', // Product mode, obtained when entering the system or refreshing the page},
 mutations:
 // Change product mode changeProductMode: function (state, value) {
  state.productMode = value;
 },
 },
 actions: {
 async SET_PRODUCT_MODE({ commit, state }) {
  let res = await portService.getProductMode();
  if (res.data.code === 0) {
  commit('changeProductMode', res.data.data.productMode);
  }
  // If it is a digital product if (state.productMode === globalConstant.COMMON.AAS) {
  // Set up the product login page router.addRoutes([
   {
   path: '/login',
   name: 'login',
   component: resolve => {
    require(['@/views/login.vue'], resolve);
   },
   }
  ]);

  //Merge http requests and attach them to the Vue prototype Vue.prototype.portService = Object.assign(portService, httpAAS);
  }
  // If it is a firewall product else if (state.productMode === globalConstant.COMMON.DBSG) {
  // Set up the product login page router.addRoutes([
   {
   path: '/login',
   name: 'login',
   component: resolve => {
    require(['@/views/views-fw/login.vue'], resolve);
   },
   }
  ]);

  //Merge http requests and attach them to the Vue prototype Vue.prototype.portService = Object.assign(portService, httpFW);
  }
 }
 }
};

Summarize

After the split, the code directories of the data audit and the firewall have been basically separated. This process took a lot of effort and also triggered some thoughts in me: is it a good idea to have one set of code for multiple projects? Are there any better solutions? If the project is developed according to the design of multiple projects with one set of code from the beginning, will the subsequent maintenance cost be lower? I don’t have the answers to these questions, but I hope that future generations can inherit historical experience and develop better projects.

Other Implementations

When the splitting plan was first designed, there were two options. One was to dynamically change the current product function by obtaining the product model, and the other was to package the specified product package through packaging parameters during packaging. The final solution is to choose the first one. However, in this process, we also referred to some online implementation solutions, which are listed here for future reference.

//www.jb51.net/article/188869.htm

//www.jb51.net/article/207835.htm

The above is the detailed content of the Vue project code splitting plan. For more information about Vue project code splitting, please pay attention to other related articles on 123WORDPRESS.COM!