preface

Through this question, I will see a series of project optimizations I made in the vUE project, and then see the different dimensions to classify these points.

This is more of a design consideration, an outline, not the actual code.

The project architecture

Modular design idea

After receiving the project, the corresponding three parts of Store, Router and XHR were firstly divided into molecular modules, and the partition dimensions of each sub-module were different.

  • The partition dimension of store modules is data correlation. Since store itself supports the combination of modules and uses are mixed together, we will still mix modules in index.
  • One router is carried out in accordance with the business of the module, or dimension points according to the page, each level routing points a routing module, the secondary routing for the name of the page, which sets the level of routing to folder name, secondary routing path and the name of the page, with the same in order to simplify this part, the name of the primary routing as the ‘scope’, In order to support lazy loading and optimized writing of imported components at the same time, the optimization method of _import is written, which can import corresponding components in batches according to the file name, and divide the routing code in the production environment. The different modules are then finally aggregated into the router’s modules.
  • The XHR part is divided into modules according to the back-end microservices for easy viewing and maintenance. According to the interface level of the back end, we decide whether to divide the second-level object attributes, in which the exposed method has the same name as the back end. Subsequently, we also decide to optimize this part of the handwritten code by using easyMock to generate API methods in batches. Considering that almost no page or component uses more than two API microservice requests, this is why I didn’t collect and aggregate each business API in index.js, choosing instead to load on demand at development time. For apis with high versatility, I will define them in index.js on the one hand, and expose these data in VUEX on the other hand to achieve this purpose.
  • As an additional introduction, in addition to the above three, I also set up a sub-business module implementation for the SRC root directory filter. This is partly due to the lack of business coupling, so only the core tool filters are exposed in index.js, and the rest are introduced on demand.

Common components within a business

Different from some of you, I write some components that are more business-specific, but some split components that are common to the current business are defined in the components directory of each business, rather than in SRC/Components, which I call the common components within the business.

Intra-business enumeration and global enumeration

In fact, many times you will encounter enumeration data, either defined by the back end, defined by the front end, or requested by the interface but largely unchanged. It may be ok to have fewer enumerations, but if a data item has more than ten enumerations that are used by more than two pages, you should consider maintaining them in a separate enumeration dictionary file. So first of all, I suggest that the enumeration based on this business should be built in the root directory of the business to create an ENUM JS enumeration file, which is solely used to host the enumeration in the business. But more often than not, there are some annoying parts:

Enumerations in the 1 business are found to be useful in other pages than this level 1 business page. So you can think about it this way: first of all, you must maintain a piece of data, then where is the maintenance, if it is the core business, then maintain the global enumeration warehouse, and then introduce or modify it as needed in the business. If it’s a peripheral business, use it occasionally, and I personally think it’s better to maintain enumerations in the business.

Enumeration and filter and field translation. In fact, enumeration fields are not only used for enumeration, but also will inevitably act as some drop-down boxes, display values of the traversal source, can also be used as a translation source for field translation, and can also be used as some of our business field filters. Once this part is understood, it is of great benefit for us to optimize and collate the business data types in our projects.

3 Global enumeration of service filters and universal filters. Of course, the functions of these filters are not only based on the basic part, but also based on the collected part of the service filter maintenance. It is also used as a corresponding method to obtain the syntax of the corresponding value conversion value.

Common components

  • Pure UI components, elementUI components further encapsulate some of their own project requirements in terms of their official maintenance.
  • Basic layout components within the layout, including the page structure, menu, top, theme page.
  • Feature business components that can be decomposed into any page and any location can be displayed on any page and only the corresponding service data requirements are required.
  • Functional components including picture uploads, custom modal boxes

theme

To maintain the basic style, you set some basic theme variables and then modify the style colors for the core components of ElementUI.

Axios intercept

Intercept before and after the request for the axios part, translate for the specific status code, verify the necessary vuEX interface token necessity in this setting and introduce the prompt component for the necessary interface prompt.

To meet the requirements of service integration, the series and parallel requests of interfaces are optimized.

mixins

Mix in common optimization methods with mixins.

Typical code snippet optimization

Use data as logic to reduce display control of labels

You’ll see a lot of things that the front end will do based on one field of the data, and then write v-if to decide whether or not that label is displayed, and then not that field, another one is displayed. It is suggested that in the display control of objects or arrays, data modification can be carried out directly according to the required data, and similar component rendering can be judged without multiple conditions. This code can be simple with a label bearing, the content of the display difference can be simple with three items, complex should be in the JS method after transformation or filter implementation.

<span v-if="sex===male"> male </span> <span v-else > female <span>Copy the code

Lingering static copy writing

Vue provides good array looping and object looping methods, so when we implement similar page requirements, it is not recommended to write a lot of unmaintainable page lists as before. To maintain it in an array and then implement it in a V-for loop, because a lot of this code takes up space, is not a good understanding of what VM means.

<option value='1'>1</option>
<option value='2'>2</option>
<option value='3'>3 </option>
Copy the code

Else can’t think of any other logical way to do it than if

And then you see a whole bunch of people saying if, age===0, judgment, else if and so on. And in addition to that you have switch, object property literal method, switch method, etc. Don’t let nested if,else loops be the only way we can write code.

<option value='0'>0</option>
<option value='18'> Minor </option> <option value='60'> age < / option >Copy the code

In the update,