01
前言
不知道小伙伴们有没有感觉到,为什么我和别一做一样的开发,经验水平也都差不多,为什么别人的工资就是要比我的高,领导和同喜也都比较喜欢他呢?
确实,当两个人的水平经验都差不多的情况下,有些人写的代码就是要好点,让人看起来很舒服,而且维护起来修改功能人家也比较快。这是什么原因呢,其实就是两个字:规范
好的一个代码习惯,可以起到事半功倍的效果。相反,乱写一气,命名不规范,过段时间自己都不看懂到底是怎么回事,这样的人肯定是不会受老板领导甚至同事的喜欢,以后涨薪也不会优先考虑到你。
下面我们介绍一下关于在Vue开发过程中,一些比较好的规范,让大家都能写出漂亮的代码。
02
开发工具的选择
相信很多人都喜欢用自己的熟练的开发工具都做开发,这无可厚非,但是当我们来到一个新的公司,同事都用的别的开发工具,而你自己别的开发工具,就拿前端来说吧,有的人喜欢用 vscode,有的喜欢用 webstorm,甚至还有小伙伴喜欢用sublime等一些开发工具。如果是您个人开发的话这是可以的,但现实往往是一个团队一起开发,这样我们就不能根据自己的喜好去选择,而是应该跟着团队一起用一样的开发工具。 一定要记得工具就是为了提高开发效率而来的,切不可一成不变。只有适合的没有好与坏,跟着大家一起才能把事情做好。
03
vue下的常见开发规范
关于页面或者组件
- 组件名应该始终由多个单词组成,除了根组件
App
,以及<transition>
、<component>
之类的 Vue 内置组件。 比如:Todo,我们应该命名成:TodoItem 或者 todo-item 不要起单个单词的名字,这样有可能会和html中的标签冲突 - 只要有能够拼接文件的构建系统,就把每个组件单独分成文件。对于组件的文件名要么始终是单词大写开头 (PascalCase),要么始终是横线连接 (kebab-case)。切不可两者混用, 如:myComponent,应该是 MyComponent 或者 my-component 个人比较喜欢的是:页面采用kebab-case写法,组件采用PascalCase。这样一眼就可以看出哪个.vue是页面哪个.vue是组件。方便查找
- 自闭合的组件使用方式:
在单文件组件、字符串模板和JSX中应该使用
<MyComponet/>
在DOM中应该使用
<my-component></my-component>
<my-component></my-component>
关于Props
- 在写的代码中,prop 的定义应该尽量详细,至少指定其类型。
避免:
props: ['status']
这样的写法 要尽可能描述清楚,如:
props: {
status: {
type: String,
required: true,
validator: value => {
return [
'syncing',
'synced',
'version-conflict',
'error'
].includes(value)
}
}
}
- 在命名变量的时候,要采用camelCase写法,在使用的时候要采用kebab-case写法。看下面的例子:
不好的写法
代码语言:javascript复制// 定义
props: {
'greeting-text': String
}
// 使用
<WelcomeMessage greetingText="hi"/>
好的写法
代码语言:javascript复制// 定义
props: {
greetingText: String
}
// 使用
<WelcomeMessage greeting-text="hi"/>
关于v-for的使用
- 在使用v-for的时候,要记住一个不变的规则,就是添加 key 属性。这也是在面试中经常问到的知识。
同时要记得尽量避免 index下标作为key属性的值。尽可能的使用 id
- 永远不要在一个元素上同时使用
v-if
和v-for
。
这也是一个常问的面试题,大家一定要知道原理是什么,就是因为 v-if 的优先级要比 v-for 的优先级高,如果在v-if的里面使用v-for的变量,会拿不到该变量,因为还没有执行到v-for。另外也是因为效率的问题,每次循环都要经过一次 if 判断,会影响页面的渲染。
如果真的要在一起用可以使用下面的方法:
代码语言:javascript复制<ul>
<template v-for="user in users" :key="user.id">
<li v-if="user.isActive">
{{ user.name }}
</li>
</template>
</ul>
其它方面的规范
- 要为组件样式设置作用域,添加 scoped 属性,避免造成全局的css污染
- 组件/实例选项的顺序
- 全局感知 (要求在组件以外被感知)
name
- 模板编译选项 (改变模板编译的方式)
compilerOptions
- 模板依赖 (模板内使用的资源)
components
directives
- 组合 (合并 property 至选项内)
extends
mixins
provide
/inject
- 接口 (组件的接口)
inheritAttrs
props
emits
expose
- 组合式 API (使用组合式 API 的入口点)
setup
- 本地状态 (本地的响应式 property)
data
computed
- 事件 (通过响应式事件触发的回调)
beforeCreate
created
beforeMount
mounted
beforeUpdate
updated
activated
deactivated
beforeUnmount
unmounted
errorCaptured
renderTracked
renderTriggered
watch
- 生命周期事件 (按照它们被调用的顺序)
- 非响应式的 property (不依赖响应性系统的实例 property)
methods
- 渲染 (组件输出的声明式描述)
template
/render
- 全局感知 (要求在组件以外被感知)
04
总结
每个公司或者团队在开发规范方面要求不尽相同,以上只是我个人在开发的时候用到的一些规范,不等于其它人或者团队也是这样的要求,我们要做的就是应该尽快适应团队的开发规范。 也可以通过一些工具如:eslint 或者 prettier 等来帮助我们自动格式化代码,这样在写的时候效率也会大大的提高。 最后祝大家都能写出漂亮的代码