Vue 代码风格指南

时间  2019-11-16
标签 vue 代码 风格 指南 繁體版
原文   原文链接

前言

这里是官方的 Vue 特有代码的风格指南。若是在工程中使用 Vue，为了回避错误、小纠结和反模式，该指南是份不错的参考。vue

规则归类

优先级 A：必要

这些规则会帮你规避错误，因此学习并接受它们带来的所有代价吧。这里面可能存在例外，但应该很是少，且只有你同时精通 JavaScript 和 Vue 才能够这样作。vuex

优先级 B：推荐

这些规则可以在绝大多数工程中改善可读性和开发体验。即便你违反了，代码仍是能照常运行，但例外应该尽量少且有合理的理由。数组

优先级 C：谨慎使用

有些 Vue 特性的存在是为了照顾极端状况或帮助老代码的平稳迁移。当被过分使用时，这些特性会让你的代码难于维护甚至变成 bug 的来源。这些规则是为了给有潜在风险的特性敲个警钟，并说明它们何时不该该使用以及为何。编辑器

优先级 A 的规则：必要的 (规避错误)

组件名为多个单词 必要

组件名应该始终是多个单词的，根组件 App 以及 <transition>、 <component> 之类的 Vue 内置组件除外。函数

这样作能够避免跟现有的以及将来的 HTML 元素相冲突，由于全部的 HTML 元素名称都是单个单词的。工具

反例

  1. Vue.component('todo', {

// ...

})

export default {

name: 'Todo',

// ...

}

     

好例子

  1. Vue.component('todo-item', {

// ...

})

export default {

　　name: 'TodoItem',

// ...

}

     

组件数据 必要

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

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

详解

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

  1. data: {

   listTitle: '',

　　todos: []

}

     

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

取而代之的是，咱们但愿每一个组件实例都管理其本身的数据。为了作到这一点，每一个实例必须生成一个独立的数据对象。在 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. })

  4.  

  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>

  4.  

  5. <style scoped>

  6. button {

  7. background-color: red;

  8. }

  9. </style>

好例子

  1. <template>

  2. <button class="btn btn-close">X</button>

  3. </template>

  4.  

  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="$emit('input', $event.target.value)"

  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>

  10.  

  11. <script>

  12. import { mapActions } from 'vuex'

  13.  

  14. export default {

  15. props: {

  16. todo: {

  17. type: Object,

  18. required: true

  19. }

  20. },

  21. methods: mapActions(['removeTodo'])

  22. }

  23. </script>

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程