Hi, everybody. I’m your unfortunate old wangly.Recently the volume of the project is increasing, and the architecture of the project has become very bad. Severe centralization and unclear modularization lead to very messy subsequent development. I wrote an article for myself on the concept of centralization. I’ve also noticed that some of the front ends have been working for a year or morecentralized, anddecentralizedThe concept of. This situation is very bad. Without a good understanding of the project at the beginning, the project will become more and more chaotic with the development of the project volume.

This article is theoretical, read it if it will help you. Might as well give it a thumbs up.

Centralization & decentralization

The so-called central words in plain English are actually toXBe centered on, depend onXThings are going fastXBody aggregation, let’s use a hand diagram to describe what centralization looks like. It can be seen from the picture thatXIs centered and diverges very dense nodes.

The decentralized structure is similar to the engineering Module scheme, which classifies X divergent nodes in the form of sub-molecules. Similar to the bifurcation diagram below. As you can see, the nodes are planned with a master node.


Vue project structure

I used my own drawing skills to draw a relatively rough composition of Vue project, and only drew some commonly used structures.

In the Vue project, it is declared in the form of componentization, dividing the page into components. Load it in the form of routes. So in these structures, with the accumulation of business, there will be no lack of centralization problems. Makes code stack difficult to maintain. The easiest places to centralize are components and routing modules. Mocks and apis and Vuex are also easy to centralize without careful management.

How to better manage projects, decentralization?

There is a problem, and it needs to be solved. The best way to solve this problem is to de-center modularity. Let’s look at what a bad centralized routing module looks like.

It looks like there’s nothing wrong with it, but the question is will we have at least one page40 +Scale, and the model will look as dense as the centralized graph. The rendering of this model to the page is to write all the route declarations in a JS file, and then whether adding routes or deleting routes, it is a very troublesome thing to find. So we need to decentralize the project modules. Achieve a multi – node multi – branch structure.

Route decentralization

The above mentioned routing centralization problem, so here to solve the next. In the case of such methods, file declarations are registered. Require. context in Webpack solves this problem nicely.

Official description of require.context: Click to go

throughrequire.contextPerform import analysis on folders. The exported content is combined and mounted to a routing instance. So start by creating two test routing files.throughrequire.contextLet’s take a look at the file that we imported

const routerFiles: __WebpackModuleApi.RequireContext = require.context('./module'.true./\.ts$/)
console.log(routerFiles.keys())
Copy the code

After obtaining the context of the import file, try to obtain the default export to see if the route can be obtained, as shown in the following figure. We get the export of the first TS file.

const routerFiles: __WebpackModuleApi.RequireContext = require.context('./module'.true./\.ts$/)
console.log(routerFiles.keys())
console.log(routerFiles(routerFiles.keys()[0]).default)
Copy the code

Now that I can get it. Then we just need to get all the file content to concatenate to get the complete route list. As shown below, a route list has been generated.

import { RouteConfig } from 'vue-router'
const routerFiles: __WebpackModuleApi.RequireContext = require.context('./module'.true./\.ts$/)
const routerList: RouteConfig[] = []

routerFiles.keys().forEach((fileName:string) = > {
 if (routerFiles(fileName).default instanceof Array) {  routerList.concat(routerFiles(fileName).default)  } else {  routerList.push(routerFiles(fileName).default)  } }) console.log(routerList)  Copy the code

With the above code, we can manage the routing table by simply declaring the routing file under the folder and exporting the RouteConfig object. A route needs to be modified. You only need to modify the file object corresponding to the route.

This is a very simple route decentralization. Not much code, easy to understand. In fact, for routing management, Nuxt’s contracted routing is let me move. One item: (●’◡’●).

Vuex modular

Bad Vuex is state, mutations, actions, and getters. It looks very messy. So global variable management is very unfriendly. Confounding variables often occurs. Bad for management. There is a misunderstanding about what state and actions do. As the content of Vuex increases, the problem of centralization gradually emerges.

So it’s best to use Vuex’s built-in modularity. And open the namespace. Then you can modularize Vuex. ModuleName/XXX is available for subsequent use.

import { MutationTree } from 'vuex'
// Vuex parameter interface
export interface IApp {
  isShowToolBar: boolean
  colorTheme: string
}  / / state const state: IApp = {  isShowToolBar: true. colorTheme: '#515a6e' }  / / method of mutations const mutations: MutationTree<any> = {  setShowToolBar: (state: IApp, bool: boolean) = > {  state.isShowToolBar = bool  },   setColorTheme: (state: IApp, color: string) = > {  state.colorTheme = color  } }  export default {  namespaced: true. state,  mutations } Copy the code

Requests are separated from views.

Today, you can also see some developers putting Network Request code in views, which makes interface maintenance more difficult as the business code increments. Separating API requests is an elegant way to manage them as you simply fetch data directly from the view page and assign it to the variables that the page needs.


const { data } = await _api_mock_login(params)
Copy the code

Component decentralization

We manage the components of the page in the same way as routing. Here is a comparison of the project structure. Each page does its own independent management. Never stack it in the root file of your own project. Otherwise, pages and components are very unrecognizable. People who dig holes for others.

Don’t friendly
friendly

Conclusion the latter

When developing a Vue project, it is best to use modularity to manage the project without creating file redundancy. Use the require.context feature properly to make a declaration to the project file. For a Vue project, it can be very difficult to manage it properly and you need to dig through the files to find things. So the best approach is for one module to try to do what the current module does and separate out what other modules need to do. Minimize coupling. Try not to have your projects stacked and centralized.

Give it a thumbs up if you think it helps. Find another job. Shanghai, Hangzhou, Guangzhou and Shenzhen are ok.