Good development habits, I have a few suggestions

This article does not introduce how to optimize the performance of the project, but introduces some development experience summarized in my work, aiming to improve work efficiency by improving development habits.

Northeastern people have a very interesting word, called "Maitai". Haha, I wonder if you guys have heard your friends say this. In life, we certainly don't want others to dislike us for being "Maitai". Similarly, our projects should not be "Maitai". Formulating an excellent project structure not only makes us feel comfortable, but also provides great convenience for me in daily code maintenance. Therefore, I have summarized some optimization tips for the front-end project structure at work, and I would like to share them with you.

1. Project directory optimization

This may be the last thing many people pay attention to, but it is the key to influencing your visual development.

Correct use of static folder

Static means static, which means that some fixed resources should be put into static, such as the static folder provided by vue-cli, which can store some fixed resources, such as 404 pictures and other image resources, .js files storing regional codes, etc. Putting these resources in static is not only convenient for introduction, but also the files in static will not be processed by webpack, which can further save packaging time.

There should be a util toolbox

Util, tool, as the name implies, is a folder for storing various tool functions. In the project, it is inevitable to use repeated processing functions, such as deepClone, floatCheck, moneyFormat, etc. There are so many places to use them, and it is obviously unreasonable to copy these functions on each page. Therefore, we put these public tool functions in the util folder, so that when we use them, we can directly import them, modify them uniformly when modifying a certain function, and perform special processing according to the parameters.

Note that util should also be reasonably classified according to the function. So your util should be a toolbox, not a toolbar.

Pay attention to reasonable classification using folders

I think there must be many people who read my sharing and have the following problems in processing files:

Maybe the above example is not too bad, as there are not many files and the naming format is consistent. But if there are many files and the naming is inconsistent, you can imagine that when you are doing code maintenance, it may take a while just to find the target code.

Therefore, it is recommended to subdivide the files by function as shown below (but pay attention to the fine-grainedness of the division, stop at a reasonable level, and do not divide them too detailed), so that when we review the code, we can lock the location of our target file according to the folder and quickly locate the target. Don't be afraid of too many folders, improving work efficiency is our ultimate goal.

Unified management of requests and interfaces

In each project, I will set aside a folder like this. Just from the name, you can tell that this is a folder for managing requests.

I will put all the processing related to http requests into http.js for management. For example, as shown below, the processing of parameters and request methods are encapsulated inside. When a method is exposed, you only need to pass in the relevant interface, parameters, and request methods when using it, and you don't need to consider other logical processing.

I think it is necessary to mention the management of request interfaces. Because once when I took on a project, I found that all the request APIs were hard-coded in the request method. It was really fun to write it, but it took a long time to modify and find it, and it took a lot of effort to complete the work.

At present, my management of request interfaces is to put all interfaces into a unified file. When calling related interfaces, they are directly obtained from the request.js file. The advantage of this is that it avoids the taboo method of hard coding. At the same time, when there are multiple calls to an interface, you only need to import them to obtain them. In addition, it is very convenient to maintain.

In fact, it is relatively easy to maintain. When the number of interfaces reaches a certain amount, putting all interfaces in one file will make it look a bit bloated (on the right side of the picture above, you can see densely packed interfaces), but this problem does not seem to be that critical. So, the specific trade-off here can refer to the third point above.

config folder, move your configuration operations here

(Note: The config folder mentioned above refers to configuration in general, not a specific name, because using the name config is likely to conflict with some scaffolding names)

Regardless of the size of the application, the initialization of the project is always necessary. If you need to configure a lot of options, such as the initialization of axios in Vue, request interceptors, response interceptors, route initialization, global hook settings, and other basic configurations, we can't put all these things in main.js. So, we have the following structure

Put the initialization operations, fixed enumeration values ​​or other configuration contents in a unified location. This will make it easier for us to modify the configuration contents, especially when adding new configurations, we can directly add the corresponding contents with a purpose.

There is a point here. For example, if two files in the project need to import Vue, then write import Vue from 'vue' in each file, which will cause Vue to be imported once more when the project is packaged, increasing the size of the project. Therefore, it is recommended to expose a reference to Vue when importing Vue, export let _Vue = Vue, instead of repeatedly using the import syntax.

2. Coding habits

Component naming: /area-selector/area-selector.vue vs. /area-selector/index.vue

In the early stage of project development, I used the former way of writing, but later I changed to the latter way of writing. The reason is very simple. The naming of the component folder can fully express the function of the component, so the component does not need to repeat this description. In addition, when using the index.vue style, index.vue can be omitted when the component is imported, such as import areaSelector from '/xx/area-selector'.

3. Coding style

No copy and paste

Lu Xun said that copying and pasting is the root of all evil. Yes, in my opinion now, copying and pasting is indeed the source of many problems.

When writing the same page or the same validation script, I believe that many lazy people will just copy and paste large sections. At least I have many such colleagues around me. It seems that the speed of doing things is very fast, but in fact it is digging a hole for yourself, because in the end you may not even know which pages your code is used in. Once the requirements change, the code changes so much that you cry.

In my projects, I usually do a simple analysis of the requirements. When it comes to the same or similar content, I will mark it. Then in the development process, I will extract the common content and keep it for reuse. Even if there is a bug or the requirements are adjusted, I can make a change to all of them. Efficiency is the key.

Comments remind you of your past code

There are two completely different views on code comments. Many articles on code comments believe that "the best comment for code is no comment", or "code is the best comment". But in my opinion, this is pure nonsense. Really, don't be too optimistic about your memory. After a while, you may not be able to remember what the method you defined does when you have a very clear idea of ​​the code. Therefore, you must write a good comment for the code.

The book Code Complete states that "comments should account for 2/5 of a good code". When I write code to deal with general problems, I may only write 1/5 of the code as simple comments. But when dealing with some complex logic, I will write a lot of comments. I will record the designed data format, processing ideas, technical pitfalls, etc. in detail. When I go back to modify, I can skip a lot of code that does not need to be checked based on the comments.

Details Habits

Speaking of habits, here are three of mine:

• Use &&, || and ternary operators to replace if...else

For example, if we modify the assignment statement to use logical operators, we can simplify our code a lot!

 function getValue(value) {
 let res
 if(value){
 res = value
 } else {
 res = -1
 }
 return res
 }

Modified to

 function getValue(value) {
 let res = value || -1
 return res
 }

Internally called functions are marked with "_"

For example, changing the page initialization function initPage() to _initPage() does not have any particularly outstanding benefits, but it can make you clear which methods are called inside the code.

Eliminating magic strings

The so-called magic string refers to a string that is hard-coded in the code. Such magic strings usually reduce the maintainability of the code because you may accidentally miss one of them when modifying the code.

 // Eliminate hard coding
 let preText = 'hello'  
 let nextText = 'world'  
 if( xx ) {
 // console.log( 'hello' ) //Magic string, poor maintainability
 console.log(preText)
 } else {
  // console.log( 'hello world' )
    console.log(preText + ' ' + nextText)
 }

OK, that's all I want to share. The content of this article is not new, but it is all my insights from actual operation. Part of it is my own summary, and part of it is a new understanding of the familiar theory. I sincerely hope that it can bring some value to you.