点击“开发者技术前线”，选择“星标?”
13：21 在看|星标|留言, 真爱
https://github.com/vuejs/cn.vuejs.org/blob/master/src/v2/style-guide/index.md
前言
这里是官方的 Vue 特有代码的风格指南。如果在工程中使用 Vue，为了回避错误、小纠结和反模式，该指南是份不错的参考。规则归类
优先级 A：必要
这些规则会帮你规避错误，所以学习并接受它们带来的全部代价吧。这里面可能存在例外，但应该非常少，且只有你同时精通 JavaScript 和 Vue 才可以这样做。优先级 B：推荐
这些规则能够在绝大多数工程中改善可读性和开发体验。即使你违反了，代码还是能照常运行，但例外应该尽可能少且有合理的理由。优先级 C：谨慎使用
有些 Vue 特性的存在是为了照顾极端情况或帮助老代码的平稳迁移。当被过度使用时，这些特性会让你的代码难于维护甚至变成 bug 的来源。这些规则是为了给有潜在风险的特性敲个警钟，并说明它们什么时候不应该使用以及为什么。优先级 A 的规则：必要的 (规避错误)
组件名为多个单词 必要
组件名应该始终是多个单词的，根组件App 以及 <transition>、 <component> 之类的 Vue 内置组件除外。这样做可以避免跟现有的以及未来的 HTML 元素相冲突，因为所有的 HTML 元素名称都是单个单词的。
反例
Vue.component('todo', {
// ...
})export default {
name: 'Todo',
// ...
}好例子
Vue.component('todo-item', {
// ...
})export default {
name: 'TodoItem',
// ...
}组件数据 必要
组件的data 必须是一个函数。当在组件中使用
data 属性的时候 (除了
newVue 外的任何地方)，它的值必须是返回一个对象的函数。
详解
当data 的值是一个对象时，它会在这个组件的所有实例之间共享。想象一下，假如一个
TodoList 组件的数据是这样的：
data: {
listTitle: '',
todos: []
}data: function () {
return {
listTitle: '',
todos: []
}
}反例
Vue.component('some-comp', {
data: {
foo: 'bar'
}
})export default {
data: {
foo: 'bar'
}
}好例子
Vue.component('some-comp', {
data: function () {
return {
foo: 'bar'
}
}
})// In a .vue file
export default {
data () {
return {
foo: 'bar'
}
}
}// 在一个 Vue 的根实例上直接使用对象是可以的，
// 因为只存在一个这样的实例。
new Vue({
data: {
foo: 'bar'
}
})Prop 定义 必要
Prop 定义应该尽量详细。在你提交的代码中，prop 的定义应该尽量详细，至少需要指定其类型。详解
细致的 prop 定义有两个好处：它们写明了组件的 API，所以很容易看懂组件的用法；
在开发环境下，如果向一个组件提供格式不正确的 prop，Vue 将会告警，以帮助你捕获潜在的错误来源。
反例
// 这样做只有开发原型系统时可以接受
props: ['status']好例子
props: {
status: String
}// 更好的做法！
props: {
status: {
type: String,
required: true,
validator: function (value) {
return [
'syncing',
'synced',
'version-conflict',
'error'
].indexOf(value) !== -1
}
}
}避免 v-if 和 v-for 用在一起 必要
一般我们在两种常见的情况下会倾向于这样做：
为了过滤一个列表中的项目 (比如
v-for="user in users"v-if="user.isActive")。在这种情形下，请将users替换为一个计算属性 (比如activeUsers)，让其返回过滤后的列表。为了避免渲染本应该被隐藏的列表 (比如
v-for="user in users"v-if="shouldShowUsers")。这种情形下，请将v-if移动至容器元素上 (比如ul,ol)。
详解
当 Vue 处理指令时，v-for 比
v-if 具有更高的优先级，所以这个模板：
<ul>
<li
v-for="user in users"
v-if="user.isActive"
:key="user.id"
>
{{ user.name }}
</li>
</ul>this.users.map(function (user) {
if (user.isActive) {
return user.name
}
})computed: {
activeUsers: function () {
return this.users.filter(function (user) {
return user.isActive
})
}
}<ul>
<li
v-for="user in activeUsers"
:key="user.id"
>
{{ user.name }}
</li>
</ul>过滤后的列表只会在
users数组发生相关变化时才被重新运算，过滤更高效。使用
v-for="user in activeUsers"之后，我们在渲染的时候只遍历活跃用户，渲染更高效。解藕渲染层的逻辑，可维护性 (对逻辑的更改和扩展) 更强。
<ul>
<li
v-for="user in users"
v-if="shouldShowUsers"
:key="user.id"
>
{{ user.name }}
</li>
</ul><ul v-if="shouldShowUsers">
<li
v-for="user in users"
:key="user.id"
>
{{ user.name }}
</li>
</ul>v-if 移动到容器元素，我们不会再对列表中的每个用户检查
shouldShowUsers。取而代之的是，我们只检查它一次，且不会在
shouldShowUsers 为否的时候运算
v-for。
反例
<ul>
<li
v-for="user in users"
v-if="user.isActive"
:key="user.id"
>
{{ user.name }}
</li>
</ul><ul>
<li
v-for="user in users"
v-if="shouldShowUsers"
:key="user.id"
>
{{ user.name }}
</li>
</ul>好例子
<ul>
<li
v-for="user in activeUsers"
:key="user.id"
>
{{ user.name }}
</li>
</ul><ul v-if="shouldShowUsers">
<li
v-for="user in users"
:key="user.id"
>
{{ user.name }}
</li>
</ul>优先级 B 的规则：推荐 (增强可读性)
组件文件 推荐
只要有能够拼接文件的构建系统，就把每个组件单独分成文件。当你需要编辑一个组件或查阅一个组件的用法时，可以更快速的找到它。反例
Vue.component('TodoList', {
// ...
})
Vue.component('TodoItem', {
// ...
})好例子
components/
|- TodoList.js
|- TodoItem.jscomponents/
|- TodoList.vue
|- TodoItem.vue组件名中的单词顺序 推荐
组件名应该以高级别的 (通常是一般化描述的) 单词开头，以描述性的修饰词结尾。要注意 在你的应用中所谓的“高级别”是跟语境有关的。比如对于一个带搜索表单的应用来说，它可能包含这样的组件：components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vuecomponents/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputExcludeGlob.vue
|- SearchInputQuery.vue
|- SettingsCheckboxLaunchOnStartup.vue
|- SettingsCheckboxTerms.vue在多级目录间找来找去，要比在单个
components目录下滚动查找要花费更多的精力。存在组件重名 (比如存在多个
ButtonDelete组件) 的时候在编辑器里更难快速定位。让重构变得更难，因为为一个移动了的组件更新相关引用时，查找/替换通常并不高效。
反例
components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue好例子
components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputQuery.vue
|- SearchInputExcludeGlob.vue
|- SettingsCheckboxTerms.vue
|- SettingsCheckboxLaunchOnStartup.vue完整单词的组件名 推荐
组件名应该倾向于完整单词而不是缩写。编辑器中的自动补全已经让书写长命名的代价非常之低了，而其带来的明确性却是非常宝贵的。不常用的缩写尤其应该避免。反例
components/
|- SdSettings.vue
|- UProfOpts.vue好例子
components/
|- StudentDashboardSettings.vue
|- UserProfileOptions.vueProp 名大小写 推荐
在声明 prop 的时候，其命名应该始终使用 camelCase，而在模板和 JSX 中应该始终使用 kebab-case。我们单纯的遵循每个语言的约定。在 JavaScript 中更自然的是 camelCase。而在 HTML 中则是 kebab-case。反例
props: {
'greeting-text': String
}好例子
props: {
greetingText: String
}多个特性的元素 推荐
多个特性的元素应该分多行撰写，每个特性一行。在 JavaScript 中，用多行分隔对象的多个属性是很常见的最佳实践，因为这样更易读。模板和 JSX 值得我们做相同的考虑。反例
<img src="https://vuejs.org/images/logo.png" alt="Vue Logo"><MyComponent foo="a" bar="b" baz="c"/>好例子
<img
src="https://vuejs.org/images/logo.png"
alt="Vue Logo"
><MyComponent
foo="a"
bar="b"
baz="c"
/>简单的计算属性 推荐
应该把复杂计算属性分割为尽可能多的更简单的属性。详解
更简单、命名得当的计算属性是这样的：易于测试
当每个计算属性都包含一个非常简单且很少依赖的表达式时，撰写测试以确保其正确工作就会更加容易。
易于阅读
简化计算属性要求你为每一个值都起一个描述性的名称，即便它不可复用。这使得其他开发者 (以及未来的你) 更容易专注在他们关心的代码上并搞清楚发生了什么。
更好的“拥抱变化”
任何能够命名的值都可能用在视图上。举个例子，我们可能打算展示一个信息，告诉用户他们存了多少钱；也可能打算计算税费，但是可能会分开展现，而不是作为总价的一部分。
小的、专注的计算属性减少了信息使用时的假设性限制，所以需求变更时也用不着那么多重构了。
反例
computed: {
price: function () {
var basePrice = this.manufactureCost / (1 - this.profitMargin)
return (
basePrice -
basePrice * (this.discountPercent || 0)
)
}
}好例子
computed: {
basePrice: function () {
return this.manufactureCost / (1 - this.profitMargin)
},
discount: function () {
return this.basePrice * (this.discountPercent || 0)
},
finalPrice: function () {
return this.basePrice - this.discount
}
}优先级 C 的规则：谨慎使用 (有潜在危险的模式)
没有在 v-if/ v-else-if/ v-else 中使用 key 谨慎使用
如果一组 v-if + v-else 的元素类型相同，最好使用 key (比如两个 <div> 元素)。默认情况下，Vue 会尽可能高效的更新 DOM。这意味着其在相同类型的元素之间切换时，会修补已存在的元素，而不是将旧的元素移除然后在同一位置添加一个新元素。如果本不相同的元素被识别为相同，则会出现意料之外的结果。
反例
<div v-if="error">
错误：{{ error }}
</div>
<div v-else>
{{ results }}
</div>好例子
<div
v-if="error"
key="search-status"
>
错误：{{ error }}
</div>
<div
v-else
key="search-results"
>
{{ results }}
</div>scoped 中的元素选择器 谨慎使用
元素选择器应该避免在 scoped 中出现。在
scoped 样式中，类选择器比元素选择器更好，因为大量使用元素选择器是很慢的。
详解
为了给样式设置作用域，Vue 会为元素添加一个独一无二的特性，例如data-v-f3f3eg9。然后修改选择器，使得在匹配选择器的元素中，只有带这个特性才会真正生效 (比如
button[data-v-f3f3eg9])。问题在于大量的元素和特性组合的选择器 (比如
button[data-v-f3f3eg9]) 会比类和特性组合的选择器慢，所以应该尽可能选用类选择器。
反例
<template>
<button>X</button>
</template>
<style scoped>
button {
background-color: red;
}
</style>好例子
<template>
<button class="btn btn-close">X</button>
</template>
<style scoped>
.btn-close {
background-color: red;
}
</style>隐性的父子组件通信 谨慎使用
应该优先通过 prop 和事件进行父子组件之间的通信，而不是this.$parent 或改变 prop。一个理想的 Vue 应用是 prop 向下传递，事件向上传递的。遵循这一约定会让你的组件更易于理解。然而，在一些边界情况下 prop 的变更或
this.$parent 能够简化两个深度耦合的组件。问题在于，这种做法在很多简单的场景下可能会更方便。但请当心，不要为了一时方便 (少写代码) 而牺牲数据流向的简洁性 (易于理解)。
反例
Vue.component('TodoItem', {
props: {
todo: {
type: Object,
required: true
}
},
template: '<input v-model="todo.text">'
})Vue.component('TodoItem', {
props: {
todo: {
type: Object,
required: true
}
},
methods: {
removeTodo () {
var vm = this
vm.$parent.todos = vm.$parent.todos.filter(function (todo) {
return todo.id !== vm.todo.id
})
}
},
template: `
<span>
{{ todo.text }}
<button @click="removeTodo">
X
</button>
</span>
`
})好例子
Vue.component('TodoItem', {
props: {
todo: {
type: Object,
required: true
}
},
template: `
<input
:value="todo.text"
@input="$emit('input', $event.target.value)"
>
`
})Vue.component('TodoItem', {
props: {
todo: {
type: Object,
required: true
}
},
template: `
<span>
{{ todo.text }}
<button @click="$emit('delete')">
X
</button>
</span>
`
})非 Flux 的全局状态管理 谨慎使用
应该优先通过 Vuex 管理全局状态，而不是通过this.$root 或一个全局事件总线。通过
this.$root 和/或全局事件总线管理状态在很多简单的情况下都是很方便的，但是并不适用于绝大多数的应用。Vuex 提供的不仅是一个管理状态的中心区域，还是组织、追踪和调试状态变更的好工具。
反例
// main.js
new Vue({
data: {
todos: []
},
created: function () {
this.$on('remove-todo', this.removeTodo)
},
methods: {
removeTodo: function (todo) {
var todoIdToRemove = todo.id
this.todos = this.todos.filter(function (todo) {
return todo.id !== todoIdToRemove
})
}
}
})好例子
// store/modules/todos.js
export default {
state: {
list: []
},
mutations: {
REMOVE_TODO (state, todoId) {
state.list = state.list.filter(todo => todo.id !== todoId)
}
},
actions: {
removeTodo ({ commit, state }, todo) {
commit('REMOVE_TODO', todo.id)
}
}
}<!-- TodoItem.vue -->
<template>
<span>
{{ todo.text }}
<button @click="removeTodo(todo)">
X
</button>
</span>
</template>
<script>
import { mapActions } from 'vuex'
export default {
props: {
todo: {
type: Object,
required: true
}
},
methods: mapActions(['removeTodo'])
}
</script>
---END---
选择”开发者技术前线 “星标?，内容一触即达。点击原文更多惊喜！
开发者技术前线 汇集技术前线快讯和关注行业趋势，大厂干货，是开发者经历和成长的优秀指南。
历史推荐
点个在看，解锁更多惊喜！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
