二.Vue项目规范

（一） Vue 编码规范

vue项目规范以Vue官方规范中的A规范为基础。

2.1.1 组件规范

1）组件名为多个单词

组件名应该始终是多个单词组成（大于等于2），且命名规范为PascalCase。

正确示例：name : 'TodoItem'

错误示例：name : 'Todo'   、 name: 'todo-item'

个人感悟：很正常的要求啊，避免和html元素冲突的一种设置。

2）组件文件名要么始终是单词大写开头 (PascalCase)，要么始终是横线连接（kebab-case)。

正确示例：my-component.vue   MyComponent.vue

错误示例：mycomponent.vue   myComponent.vue

个人感悟：本人就经常命名成myComponent，得改得改。 

3）基础组件文件名为base开头，使用完整单词而不是缩写

正确示例：base-button.vue   base-table.vue

错误示例：MyButton.vue  VueTable.vue

个人感悟：这个错误也是很经典，很多时候真的会定义成MyButton。

4）和父组件紧密耦合的子组件应该以父组件名为前缀命名

正确示例：todo-list.vue        user-profile-options.vue

错误示例：UProfOpts.vue

个人感悟：别怕名字长，就怕别人看不懂。

5）在Template模板中使用组件，应使用PascalCase模式，并且使用自闭合组件。

正确示例： <MyComponent />

错误示例：<my-component />

个人感悟： 记得Vue是能识别对于的大小写的，所以按规范来就好。

6）组件的data必须是一个函数

当在组件中使用data属性的时候，它的值必须是返回一个对象的函数。因为如果直接是一个对象的话，子组件之间的属性值会互相影响。

个人感悟：这个在开发中真没遇到过，基本上每个人都会将data设置为函数。

7）Prop定义应该尽量详细

必须使用camelCase驼峰命名

必须指定类型

必须加上注释，表面其含义

必须加上required 或者 default ，二者二选其一

如果有业务需求，必须加上 validator 验证

正确示例：

props: {

// 组件状态，用于控制组件的颜色

        status: {

                type: String,

                required: true,

                validator: function (value) {

                        return [

                                'succ',

                                'info',

                                'error'

                                ].indexOf(value) !== -1

                }

        },

// 用户级别，用于显示皇冠个数

        userLevel：{

                type: String,

                required: true

        }

}

个人感悟：很详细很细致的规范，严格执行就好。

8）为组件样式设置作用域

个人感悟：就是组件样式里style加上一个scoped，能有效防止样式互相污染和影响。

9）如果特性元素较多，应该主动换行

个人感悟：别全部写在一行里面，我最初写代码真这样，全写一大行，看的时候很麻烦。

2.1.2 模板中使用简单的表达式

组件模板应该只包含简单的表达式，复杂的表达式应该重构为计算属性或者方法。

正确示例：

<template>

        <p>{{ normalizedFullName }}</p>

</template>

computed:{

        normalizedFullName:....

}

错误示例：

<template>

        <p>        

                {{ 

                        fullName.split(' ').map(...)...

                 }}

        </p>

</template>

个人感悟：很合理的一个规范，没什么人会希望在模板中写一长串内容吧。

2.1.3 指令都使用缩写形式

指令推荐都使用缩写形式，（用：表示v-bind、用@表示v-on、用#表示v-slot）

正确示例：

<input

        @input = "onInput"

        @focus = "onFocus"

>

错误示例：

<input

        v-on:input = "onInput"

        v-on:focus = "onFocus"

>

个人感悟：说实话作为一个小白，用久了：@#，都有点记不清原本代表了啥了。

2.1.4 标签顺序保持一致

单文件组件应该总是让标签顺序保持为 template script style

个人感悟：保持好这个顺序就行，遵守规范。

2.1.5 必须为 v-for 设置键值 key

个人感悟：貌似是一道面试题，设置上key可以防止v-for里面出现错误，就是能帮助你更好的定位要删除的内容，防止你删完顺序不对。

2.1.6 v-show 与 v-if 选择

如果运行时，需要非常频繁地切换，使用v-show；如果在运行时，条件很少改变，用v-if

个人感悟：一般情况都是v-show吧，不可避免的会有人喜欢频繁切换。

2.1.7 script 标签内部结构顺序

name>components>mixins>props>data>computed>watch>filter>钩子函数（钩子函数按其执行顺序）>methods

个人感悟：这个真的太重要了，不知道这个规范前我都是乱放位置，找起来特别麻烦。

2.1.8 Vue Router 规范

1）页面跳转数据传递使用路由参数

页面跳转，例如从A页面跳转到B页面，需要将A页面的数据传递到B页面，推荐使用路由参数传参，而不是将数据存在vuex，然后在B页面中取出vuex数据，因为如果在B页面刷新，会导致vuex数据丢失，导致B页面无法正常显示数据。

正确示例：

let id = '123'

this.$router.push({name : 'userCenter', query})

个人感悟：很好的规范，之前就是喜欢全部写到vuex或者pinia里面，就会出现描述的问题，一刷新就无法正确显示数据，有时候还会写在localstorage里，既然官方说了那就路由传参。

2）使用路由懒加载（延迟加载）机制

正确示例：

{

        path:'/uploadAttachment',

        name:'/uploadAttachment',

        meta:{

                title:'上传附件'

        }，

        component:() => import('@/view/components/uploadAttachment.index.vue')

}

个人感悟：个人确认不常用这么写，但是能按需加载的话还是对优化有效的，可以学起来。

3）router中的命名规范

path、children命名规范采用kebab-case命名规范（尽量vue文件的目录结构保持一致，因为目录、文件名都是kebab-case）

name命名规范采用kebab-case命名规范且和component组件名一致！（因为要保持keep-alive特性，keep-alive按照component的name进行缓存，所以二者必须高度保持一致）

个人感悟：说实话，一个个不同的命名规范，确实累人，但是遵守规范总是没错的。

4）router中的path命名规范

path处理采用kebab-case命名规范意外，必须以 / 开头，及时是children里的path也要以 / 开头。

目的：某个页面有问题要立刻找到这个vue文件，如果不用以/开头，path为parent和children组成的，可能经常需要在router文件里多次才能找到，而如果以/开头，则能立刻搜索到组件。

（二） Vue 项目目录

2.2.1 基础

vue项目中的所有命名一定要与后端命名统一。

比如权限：后端privilege，前端无论router，store，api等都必须使用privilege单词！

个人感悟：这个属性命名最好就是前后端都根据详细设计来命名，但是就是会有人不按规范，尤其是后端如果不按规范，前端也不得不去配合，很难受。

2.2.2 使用 Vue-cli 脚手架

使用vue-cli3 来初始化项目，项目名按照上面的命名规范。

2.2.3 目录说明

目录名按照上面的命名规范，其中components组件用大写驼峰，其余除components组件目录外的所有目录均使用kebab-case命名。

1）api目录

文件、变量命名要与后端保持一致。

此目录对应后端API接口，按照后端一个controller一个api.js文件。若项目较大时们可以按照业务划分子目录，并与后端保持一致。

api中的方法名字要与后端api url 尽量保持语义高度一致性。

对应api中的每个方法要添加注释，注释与后端swagger文档保持一致。

正确示例：

后端url：EmployeeController.java

/employee/add

/employee/delete/{id}

/employee/update

前端：employee.js

// 添加员工

function addEmployee(data) {

        return postAxios('/employee/add',data)

}

// 更新员工信息

function updateEmployee(data) {

        return postAxios('/employee/update',data)

}...

个人感悟：对应后端api也是个麻烦活，需要双方及时沟通。最好能有对应的文档。

2）assets目录

assets 为静态资源，里面存放images,styles,icons等静态资源，命名格式为kebab-case

3）components目录

此目录应按照组件进行目录划分，目录命名为kebab-case，组件命名规则也为kebab-case

4）constants目录

此目录存放项目所有常量，如果常量在vue中使用，请使用vue-enum插件。

4）router与store目录

这两个目录一定要将业务进行拆分，不能放在一个js文件里。

router尽量按照views中的结构保持一致

store按照业务进行拆分不同的js文件

6）views目录

命名要与后端、router、api保持一致。components中的组件要使用PascalCase规则。

2.2.4 注释说明

必须加注释的几个地方

公共组件使用说明

api目录的接口js文件必须加注释

store中的state，mutation，action必须加注释

vue文件中的template必须加注释，若文件较大添加start end注释

vue文件的methods ，每个method必须添加注释

vue文件的data，非常见单词要加注释

个人感悟：ai写的代码就是处处有注释，至少保证了一定的可读性。

 

2.2.5 其他

1）尽量不要手动操作DOM

因使用vue框架，所有在项目开发中尽量使用vue的数据驱动更新DOM，尽量不要手动操作DOM，包括：增删改dom元素、以及更改样式、添加事件等。

2）删除无用代码

因使用了git/svn等代码版本根据，对于无用的代码必须及时删除，例如：一些调试的console语句、无用的弃用功能代码。

个人感悟：不删console就上线，我一直以为是开玩笑。直到自己亲身经历。