Rain town building

nonsense

Actually, I didn’t think this article was necessary. However, I have been working on the front end for more than three years (I started front-end development at the end of 2015), and I found that when the back end was doing the front end, when the front end novice was entering the school, they all put together the basic conventions and norms, and slowly built up their own style and habits. And a lot of what you don’t want is the exhaustive writing. It goes where it goes.

Here I will share with you my personal habits gradually accumulated over the years. There’s the React view and there’s the Vue view. We promote each other

There are nine standard documents of Ali front end

First, my directory structure

1. Directory structure

The project is a VUE project, but react is pretty much the same.

Dist Public directory that will not be packaged. One is the default path to webpack. Img (unpacked static image) js (unpacked static JS) index.html webpack entry HTML file SRC source directory Assets static file directory, Img js (do not need to be packaged here, put under the outer public) For example, route nested parts one.vue (components) Two(folders) index.vue index.js need globally registered unified exit readme. md (too many components need to explain files) Components and business irrelevant components AntDesgin. Js (component library entry) Element.js (component library entry) index.js Unified exit for global import and registration readme. md (Too many components require documentation) Mixin Part of the global mixin, not recommended for non-global mixins. Pages routes related pages, Vue page component is more complex ComThree. Vue sub-component component index. Vue page component entry comone.vue page component index 404. Vue Power Project Business authority management center Router Routing section (not recommended to put menu management here) before. Index. js service Interface management center index.js store data center, not related to the business, mainly for configuring the cache using index.js theme style center, Index.css (SCSS,less) ensures that your output is an exit tool (utils) function center app.vue Initial template createApp.js main.js contains a lot of business logic, Browserslistrc.eslintrc.js eslint config.gitignore babel.config.js Babel config.package. Json prettier.config.js Prettier configures initial convention of readme. md project, specification writing center vue.config.js Vue packaging configuration center, Webpack, etcCopy the code

2. Personal habits in code and directory structure

Follow the principle, can directly copy the best. Also follow historical norms

1. The CSS nesting does not exceed three layers for performance reasons

You can write CSS directly on div, use parent-child selectors, and so on

3. Separate the CSS name with hyphens (-), for example, name-title

4, class files start with uppercase (basic industry habit), class function names start with uppercase

5. Uppercase component name with big camel name: NameTile

6. Component file directories are named by component names and are named with large humps

NameTile
    index.vue
Copy the code

7. If the component is single label, it must be named by the directory name or component name

For example, if the component name is test. vue, the value is

8. Multi-character non-single label components are used in this way

The above component naming principles are based on the copy-straight principle and follow the HTML specification and the general framework specification. Eslint does not enforce conventions. But once you get used to it, you’ll find it’s much more efficient to write code. Because the component name you just copy and paste basically works.

9, The files under the Pages page should not be divided according to business components, one route is a folder. For example, add index files to directories.

10. Use the routing page file in pages as follows

Pages Section of routing related pages, Vue page component is more complex ComThree. Vue sub-component component index. Vue page component entry comone.vue page component index Page component entryCopy the code

11, do not write any business related code in main.js, it is best to ensure that main.js only relevant import information

12. Individuals use the prettier specification to conventions code, and I actually like it. This will unify everyone’s code style into one

Code don’t think everyone is the same as you, to follow the project. Not every project can have a complete tool chain. Like applets.

14, about the function and variable name size hump can be, ensure that letters are clearly visible on the line. For example, I am not used to using uppercase characters for constants. I don’t always understand the same letter when I see it.

Can write notes are best to write notes

16. Add a readme. md file whenever you feel you need to add additional notes

Why is the component formation and convention specification of the directory defined in this way

In fact, we all know that we do not like to preach, say what they like to look like what. There are even said not to write notes for their own irreplaceable, if it is a joke that the best. I like my project and I can see it when I’m gone. Not because of some bogus competitiveness that makes the code suck. So I’m a code freak. So far, every colleague I have contacted has said that my project is very pleasant, unless the function is very complicated, it can be quickly mastered by experienced people.

1. Assets can also be static

This file actually has no special storage over time. Old-timers would have divided the folders into js, CSS, and IMG.

Three static resources are stored separately. But now as the project develops it seems that only IMG can be stored. However, it is still recommended that you divide folders according to your business situation. CSS is unnecessary because the business needs to be isolated.

2, businessComponents and components

The reason for this division is that as the business develops over time, our components should be divided into component library components and business hybrid components. Business mash-ups such as payment components pop-ups, some global cascading components that are business specific and you can’t split into other projects to use. If mixed with non-business components, it is possible, but difficult to find. And a thoughtful person would have thought that these non-business components would have accumulated into a component library like ElementUI.

3, a mixin

While mixins are not recommended, they are globally tainted, and if the editor is not helpful, you can’t really find the definition. But if there are, please put them here.

4, Pages (Views)

1. Why not use the View file? It’s mostly the effect of small programs, so it’s a little bit more intuitive.

2. Then why not use business modules to partition routing files?

Because your pages are actually very business related, but routing is actually business independent and can be arbitrarily combined into a new business portfolio, so if you have a strict division of routing files early on by business. Later to dismantle how to do? That would be a mess. So feel a route a file. Don’t nest layers

3. The division of files and components is mainly for clearer structure. It’s ok to have a small page when everything is stacked together, but it’s a lot of trouble

5, power

This file is not strictly divided, you can also put in business components or other. The reason I bring it up is because it’s global, it has to be at the top of the business.

6, the router

Everyone probably does the same thing, but I’ve seen a lot of open source component libraries and the like combine router and menu configuration. Then extract the route guard, etc., under another file.

The biggest problem here is that your route and page are heavily coupled, and some even combine the upper and lower names to form a new route for the sake of simplified route writing. But you have to think about how the back end is usually configured, is it just a path? And then when the back end comes back it’s full path, and you’re in pain. Because you can’t clearly control what the page path is. And the likelihood of routing conflicts will increase. So I’m just going to register the route at the code level. Don’t be seriously coupled with the business, the back end will not say to accommodate the front end to do things. Small company front end is not more!

7, store

Personal approach: as the front-end database (just like the background will write stored procedures in the database to write business logic, but now no need), only do data cache, and combine with the plug-in storege cache. Only do data cache, and unified global cache operation. Other page-independent apis are not allowed to operate on caching functions.

There we go. We need to talk about history.

A. First, what does everyone do

Umi. js (React framework) : redux, etc

Vue: vuex

This folder is typically used as a global data sharing center. In fact, what vUE didn’t do so well was that people started it the wrong way. React actually has a store.js file for every business file. This is in order to extract the common parts, in order to avoid react some performance issues and data aggregation share aspects of the way so each file below one.

When it came to VUE, people thought it was good to put it all together. But it’s really inelegant to put the heavily coupled parts of the business in the big picture. At such a high level, it is easy to think that the data can be widely shared. It’s really just for a business need.

B. New apis and data sharing methods make store functions less and less useful

1, React: hooks, provide

Vue: Vue. Observable, provide, hooks

3. Js file memory caching mechanism

Each of these can replace the store approach and make data sharing and caching work better with the business. More elegant and does not increase the loading speed of the first screen

So I define store as a front-end database, a place that only does global caching of data. And unified cache operations, the confusion of localStorge and other cache operations unified. So the structure is a little bit clearer

7. Service (Interface center)

There are no strict specifications, and packages vary from project to project. But don’t split the business interfaces into page components, that would be horrible. If we change the route, it’ll be great.

I posted a personal directory structure

Categoryserver.js Nbs. Js OrderIntention. Js orderServer.js productServer.js readme.md Base (I liked the early JQ-style Ajax calls, The axiosajax.js readme.mtips.js upload.js tool (if there is a global business wrapper, API collection types are put here) loginset.js config.js configuration centers, such as public domain names and so on, but here the store center actually takes the data couplingAjax.js and business-related packages to the index.js export readme.mdCopy the code

9, Theme

This is actually originally from the ASSETS CSS folder. Because we’ll have a lot of common CSS styles that need to be used globally. Or SCSS and so on functions, there are global skin and so on. So it’s a little bit more intuitive to factor it out.

10. Tool (utils)

Set of utility functions, nothing to talk about

Vue, createApp. js, main.js

I’ll focus on main.js and createApp.js

Even novices like to put instructions, tools and functions in main.js, but it’s important to keep the entry files clean. The entry file, like package.json, should make the dependencies of the project and the basic entry clear at a glance. With so many business tools, it’s a mess.

Summary of principles

1. The reason for this division is to make the project more intuitive and simple, so that the people who take over the project will not spend time on meaningless familiarity with the project structure

2. What does it copy, what does it do when you use it, and the code efficiency is greatly improved

3, norms follow the project, one size fits all easy to make people disgusted.

Personally, I recommend webstorm development, which is probably preferred by the old people. If it weren’t for the charge, vscode wouldn’t have anything to do. Webstorm beats the world in terms of performance and development efficiency. Just defining jump is a big deal.

Recommendation:

Alibaba front nine documents:www.yuque.com/fe9/basic