看，官方出品了 Vue 编码风格指南

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 元素名称都是单个单词的。

反例

1. Vue.component('todo', {
2. // ...
3. })

1. export default {
2. name: 'Todo',
3. // ...
4. }

好例子

1. Vue.component('todo-item', {
2. // ...
3. })

1. export default {
2. name: 'TodoItem',
3. // ...
4. }

组件数据 必要

组件的 data 必须是一个函数。

当在组件中使用 data 属性的时候 (除了 newVue 外的任何地方)，它的值必须是返回一个对象的函数。

详解

当 data 的值是一个对象时，它会在这个组件的所有实例之间共享。想象一下，假如一个 TodoList 组件的数据是这样的：

1. data: {
2. listTitle: '',
3. todos: []
4. }

我们可能希望重用这个组件，允许用户维护多个列表 (比如分为购物、心愿单、日常事务等)。这时就会产生问题。因为每个组件的实例都引用了相同的数据对象，更改其中一个列表的标题就会改变其它每一个列表的标题。增删改一个待办事项的时候也是如此。

取而代之的是，我们希望每个组件实例都管理其自己的数据。为了做到这一点，每个实例必须生成一个独立的数据对象。在 JavaScript 中，在一个函数中返回这个对象就可以了：

1. data: function () {
2. return {
3. listTitle: '',
4. todos: []
5. }
6. }

反例

1. Vue.component('some-comp', {
2. data: {
3. foo: 'bar'
4. }
5. })

1. export default {
2. data: {
3. foo: 'bar'
4. }
5. }

好例子

1. Vue.component('some-comp', {
2. data: function () {
3. return {
4. foo: 'bar'
5. }
6. }
7. })

1. // In a .vue file
2. export default {
3. data () {
4. return {
5. foo: 'bar'
6. }
7. }
8. }

1. // 在一个 Vue 的根实例上直接使用对象是可以的，
2. // 因为只存在一个这样的实例。
3. new Vue({
4. data: {
5. foo: 'bar'
6. }
7. })

Prop 定义 必要

Prop 定义应该尽量详细。

在你提交的代码中，prop 的定义应该尽量详细，至少需要指定其类型。

详解

细致的 prop 定义有两个好处：

• 它们写明了组件的 API，所以很容易看懂组件的用法；
• 在开发环境下，如果向一个组件提供格式不正确的 prop，Vue 将会告警，以帮助你捕获潜在的错误来源。

反例

1. // 这样做只有开发原型系统时可以接受
2. props: ['status']

好例子

1. props: {
2. status: String
3. }

1. // 更好的做法！
2. props: {
3. status: {
4. type: String,
5. required: true,
6. validator: function (value) {
7. return [
8. 'syncing',
9. 'synced',
10. 'version-conflict',
11. 'error'
12. ].indexOf(value) !== -1
13. }
14. }
15. }

避免 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 具有更高的优先级，所以这个模板：

1. <ul>
2. <li
3. v-for="user in users"
4. v-if="user.isActive"
5. :key="user.id"
6. >
7. {{ user.name }}
8. </li>
9. </ul>

将会经过如下运算：

1. this.users.map(function (user) {
2. if (user.isActive) {
3. return user.name
4. }
5. })

因此哪怕我们只渲染出一小部分用户的元素，也得在每次重渲染的时候遍历整个列表，不论活跃用户是否发生了变化。

通过将其更换为在如下的一个计算属性上遍历：

1. computed: {
2. activeUsers: function () {
3. return this.users.filter(function (user) {
4. return user.isActive
5. })
6. }
7. }

1. <ul>
2. <li
3. v-for="user in activeUsers"
4. :key="user.id"
5. >
6. {{ user.name }}
7. </li>
8. </ul>

我们将会获得如下好处：

• 过滤后的列表只会在 users 数组发生相关变化时才被重新运算，过滤更高效。
• 使用 v-for="user in activeUsers" 之后，我们在渲染的时候只遍历活跃用户，渲染更高效。
• 解藕渲染层的逻辑，可维护性 (对逻辑的更改和扩展) 更强。

为了获得同样的好处，我们也可以把：

1. <ul>
2. <li
3. v-for="user in users"
4. v-if="shouldShowUsers"
5. :key="user.id"
6. >
7. {{ user.name }}
8. </li>
9. </ul>

更新为：

1. <ul v-if="shouldShowUsers">
2. <li
3. v-for="user in users"
4. :key="user.id"
5. >
6. {{ user.name }}
7. </li>
8. </ul>

通过将 v-if 移动到容器元素，我们不会再对列表中的每个用户检查 shouldShowUsers。取而代之的是，我们只检查它一次，且不会在 shouldShowUsers 为否的时候运算 v-for。

反例

1. <ul>
2. <li
3. v-for="user in users"
4. v-if="user.isActive"
5. :key="user.id"
6. >
7. {{ user.name }}
8. </li>
9. </ul>

1. <ul>
2. <li
3. v-for="user in users"
4. v-if="shouldShowUsers"
5. :key="user.id"
6. >
7. {{ user.name }}
8. </li>
9. </ul>

好例子

1. <ul>
2. <li
3. v-for="user in activeUsers"
4. :key="user.id"
5. >
6. {{ user.name }}
7. </li>
8. </ul>

1. <ul v-if="shouldShowUsers">
2. <li
3. v-for="user in users"
4. :key="user.id"
5. >
6. {{ user.name }}
7. </li>
8. </ul>

优先级 B 的规则：推荐 (增强可读性)

组件文件 推荐

只要有能够拼接文件的构建系统，就把每个组件单独分成文件。

当你需要编辑一个组件或查阅一个组件的用法时，可以更快速的找到它。

反例

1. Vue.component('TodoList', {
2. // ...
3. })
5. Vue.component('TodoItem', {
6. // ...
7. })

好例子

1. components/
2. |- TodoList.js
3. |- TodoItem.js

1. components/
2. |- TodoList.vue
3. |- TodoItem.vue

组件名中的单词顺序 推荐

组件名应该以高级别的 (通常是一般化描述的) 单词开头，以描述性的修饰词结尾。

要注意在你的应用中所谓的“高级别”是跟语境有关的。比如对于一个带搜索表单的应用来说，它可能包含这样的组件：

1. components/
2. |- ClearSearchButton.vue
3. |- ExcludeFromSearchInput.vue
4. |- LaunchOnStartupCheckbox.vue
5. |- RunSearchButton.vue
6. |- SearchInput.vue
7. |- TermsCheckbox.vue

你可能注意到了，我们很难看出来哪些组件是针对搜索的。现在我们来根据规则给组件重新命名：

1. components/
2. |- SearchButtonClear.vue
3. |- SearchButtonRun.vue
4. |- SearchInputExcludeGlob.vue
5. |- SearchInputQuery.vue
6. |- SettingsCheckboxLaunchOnStartup.vue
7. |- SettingsCheckboxTerms.vue

因为编辑器通常会按字母顺序组织文件，所以现在组件之间的重要关系一目了然。

你可能想换成多级目录的方式，把所有的搜索组件放到“search”目录，把所有的设置组件放到“settings”目录。我们只推荐在非常大型 (如有 100+ 个组件) 的应用下才考虑这么做，因为：

• 在多级目录间找来找去，要比在单个 components 目录下滚动查找要花费更多的精力。
• 存在组件重名 (比如存在多个 ButtonDelete 组件) 的时候在编辑器里更难快速定位。
• 让重构变得更难，因为为一个移动了的组件更新相关引用时，查找/替换通常并不高效。

反例

1. components/
2. |- ClearSearchButton.vue
3. |- ExcludeFromSearchInput.vue
4. |- LaunchOnStartupCheckbox.vue
5. |- RunSearchButton.vue
6. |- SearchInput.vue
7. |- TermsCheckbox.vue

好例子

1. components/
2. |- SearchButtonClear.vue
3. |- SearchButtonRun.vue
4. |- SearchInputQuery.vue
5. |- SearchInputExcludeGlob.vue
6. |- SettingsCheckboxTerms.vue
7. |- SettingsCheckboxLaunchOnStartup.vue

完整单词的组件名 推荐

组件名应该倾向于完整单词而不是缩写。

编辑器中的自动补全已经让书写长命名的代价非常之低了，而其带来的明确性却是非常宝贵的。不常用的缩写尤其应该避免。

反例

1. components/
2. |- SdSettings.vue
3. |- UProfOpts.vue

好例子

1. components/
2. |- StudentDashboardSettings.vue
3. |- UserProfileOptions.vue

Prop 名大小写 推荐

在声明 prop 的时候，其命名应该始终使用 camelCase，而在模板和 JSX 中应该始终使用 kebab-case。

我们单纯的遵循每个语言的约定。在 JavaScript 中更自然的是 camelCase。而在 HTML 中则是 kebab-case。

反例

1. props: {
2. 'greeting-text': String
3. }

好例子

1. props: {
2. greetingText: String
3. }

多个特性的元素 推荐

多个特性的元素应该分多行撰写，每个特性一行。

在 JavaScript 中，用多行分隔对象的多个属性是很常见的最佳实践，因为这样更易读。模板和 JSX 值得我们做相同的考虑。

反例

1. <img src="https://vuejs.org/images/logo.png" alt="Vue Logo">

1. <MyComponent foo="a" bar="b" baz="c"/>

好例子

1. <img
2. src="https://vuejs.org/images/logo.png"
3. alt="Vue Logo"
4. >

1. <MyComponent
2. foo="a"
3. bar="b"
4. baz="c"
5. />

简单的计算属性 推荐

应该把复杂计算属性分割为尽可能多的更简单的属性。

详解

更简单、命名得当的计算属性是这样的：

• 易于测试 当每个计算属性都包含一个非常简单且很少依赖的表达式时，撰写测试以确保其正确工作就会更加容易。
• 易于阅读 简化计算属性要求你为每一个值都起一个描述性的名称，即便它不可复用。这使得其他开发者 (以及未来的你) 更容易专注在他们关心的代码上并搞清楚发生了什么。
• 更好的“拥抱变化” 任何能够命名的值都可能用在视图上。举个例子，我们可能打算展示一个信息，告诉用户他们存了多少钱；也可能打算计算税费，但是可能会分开展现，而不是作为总价的一部分。 小的、专注的计算属性减少了信息使用时的假设性限制，所以需求变更时也用不着那么多重构了。

反例

1. computed: {
2. price: function () {
3. var basePrice = this.manufactureCost / (1 - this.profitMargin)
4. return (
5. basePrice -
6. basePrice * (this.discountPercent || 0)
7. )
8. }
9. }

好例子

1. computed: {
2. basePrice: function () {
3. return this.manufactureCost / (1 - this.profitMargin)
4. },
5. discount: function () {
6. return this.basePrice * (this.discountPercent || 0)
7. },
8. finalPrice: function () {
9. return this.basePrice - this.discount
10. }
11. }

优先级 C 的规则：谨慎使用 (有潜在危险的模式)

没有在 v-if/ v-else-if/ v-else 中使用 key 谨慎使用

如果一组 v-if + v-else 的元素类型相同，最好使用 key (比如两个 <div> 元素)。

默认情况下，Vue 会尽可能高效的更新 DOM。这意味着其在相同类型的元素之间切换时，会修补已存在的元素，而不是将旧的元素移除然后在同一位置添加一个新元素。如果本不相同的元素被识别为相同，则会出现意料之外的结果。

反例

1. <div v-if="error">
2. 错误：{{ error }}
3. </div>
4. <div v-else>
5. {{ results }}
6. </div>

好例子

1. <div
2. v-if="error"
3. key="search-status"
4. >
5. 错误：{{ error }}
6. </div>
7. <div
8. v-else
9. key="search-results"
10. >
11. {{ results }}
12. </div>

scoped 中的元素选择器 谨慎使用

元素选择器应该避免在 scoped 中出现。

在 scoped 样式中，类选择器比元素选择器更好，因为大量使用元素选择器是很慢的。

详解

为了给样式设置作用域，Vue 会为元素添加一个独一无二的特性，例如 data-v-f3f3eg9。然后修改选择器，使得在匹配选择器的元素中，只有带这个特性才会真正生效 (比如 button[data-v-f3f3eg9])。

问题在于大量的元素和特性组合的选择器 (比如 button[data-v-f3f3eg9]) 会比类和特性组合的选择器慢，所以应该尽可能选用类选择器。

反例

1. <template>
2. <button>X</button>
3. </template>
5. <style scoped>
6. button {
7. background-color: red;
8. }
9. </style>

好例子

1. <template>
2. <button class="btn btn-close">X</button>
3. </template>
5. <style scoped>
6. .btn-close {
7. background-color: red;
8. }
9. </style>

隐性的父子组件通信 谨慎使用

应该优先通过 prop 和事件进行父子组件之间的通信，而不是 this.$parent 或改变 prop。

一个理想的 Vue 应用是 prop 向下传递，事件向上传递的。遵循这一约定会让你的组件更易于理解。然而，在一些边界情况下 prop 的变更或 this.$parent 能够简化两个深度耦合的组件。

问题在于，这种做法在很多简单的场景下可能会更方便。但请当心，不要为了一时方便 (少写代码) 而牺牲数据流向的简洁性 (易于理解)。

反例

1. Vue.component('TodoItem', {
2. props: {
3. todo: {
4. type: Object,
5. required: true
6. }
7. },
8. template: '<input v-model="todo.text">'
9. })

1. Vue.component('TodoItem', {
2. props: {
3. todo: {
4. type: Object,
5. required: true
6. }
7. },
8. methods: {
9. removeTodo () {
10. var vm = this
11. vm.parent.todos = vm.parent.todos.filter(function (todo) {
12. return todo.id !== vm.todo.id
13. })
14. }
15. },
16. template: `
17. <span>
18. {{ todo.text }}
19. <button @click="removeTodo">
20. X
21. </button>
22. </span>
23. `
24. })

好例子

1. Vue.component('TodoItem', {
2. props: {
3. todo: {
4. type: Object,
5. required: true
6. }
7. },
8. template: `
9. <input
10. :value="todo.text"
11. @input="
12. >
13. `
14. })

1. Vue.component('TodoItem', {
2. props: {
3. todo: {
4. type: Object,
5. required: true
6. }
7. },
8. template: `
9. <span>
10. {{ todo.text }}
11. <button @click="$emit('delete')">
12. X
13. </button>
14. </span>
15. `
16. })

非 Flux 的全局状态管理 谨慎使用

应该优先通过 Vuex 管理全局状态，而不是通过 this.$root 或一个全局事件总线。

通过 this.$root 和/或全局事件总线管理状态在很多简单的情况下都是很方便的，但是并不适用于绝大多数的应用。Vuex 提供的不仅是一个管理状态的中心区域，还是组织、追踪和调试状态变更的好工具。

反例

1. // main.js
2. new Vue({
3. data: {
4. todos: []
5. },
6. created: function () {
7. this.$on('remove-todo', this.removeTodo)
8. },
9. methods: {
10. removeTodo: function (todo) {
11. var todoIdToRemove = todo.id
12. this.todos = this.todos.filter(function (todo) {
13. return todo.id !== todoIdToRemove
14. })
15. }
16. }
17. })

好例子

1. // store/modules/todos.js
2. export default {
3. state: {
4. list: []
5. },
6. mutations: {
7. REMOVE_TODO (state, todoId) {
8. state.list = state.list.filter(todo => todo.id !== todoId)
9. }
10. },
11. actions: {
12. removeTodo ({ commit, state }, todo) {
13. commit('REMOVE_TODO', todo.id)
14. }
15. }
16. }

1. <!-- TodoItem.vue -->
2. <template>
3. <span>
4. {{ todo.text }}
5. <button @click="removeTodo(todo)">
6. X
7. </button>
8. </span>
9. </template>
11. <script>
12. import { mapActions } from 'vuex'
14. export default {
15. props: {
16. todo: {
17. type: Object,
18. required: true
19. }
20. },
21. methods: mapActions(['removeTodo'])
22. }
23. </script>

上面是vue 编程规范。而Google官方的Java编程风格规范。与其它的编程风格指南一样，这里所讨论的不仅仅是编码格式美不美观的问题， 同时也讨论一些约定及编码标准。这份规范主要侧重于我们所普遍遵循的规则， 对于那些不是明确强制要求的，我们尽量避免提供意见。