写vue的尽量按照规范来

颜酱
1,341 阅读8分钟

官方的风格指南。

本文按照自己的逻辑，稍微简化了。规范的好处是，排雷更加容易，踩雷更加艰难，项目更赏心悦目。

建议先看完官方详细的文档，然后再顺带看看这篇回忆总结下。

必要

组件名为多个单词，避免单个单词

这样做可以避免跟现有的以及未来的 HTML 元素相冲突。比如以前不小心写了个masker的组件，然不生效。

Prop 定义应该尽量详细

在开发环境下，如果向一个组件提供格式不正确的 prop，Vue 将会告警，以帮助你捕获潜在的错误来源。

props: {
  status: String
}
// 更好的做法！

props: {
  status: {
    type: String,
    required: true,
    validator: function (value) {
      return [
        'syncing',
        'synced',
        'version-conflict',
        'error'
      ].indexOf(value) !== -1
    }
  }
}

v-for必须设置key

始终添加一个唯一的键值，以便你和你的团队永远不必担心一些极端情况。也在少数对性能有严格要求的情况下，为了避免对象固化，你可以刻意做一些非常规的处理。

永远不要把 v-if 和 v-for 同时用在同一个元素上

如果有这种场景，按照下面的方式改进，以优化性能

  1. 过滤一个列表中的项目 (比如 v-for="user in users" v-if="user.isActive")。在这种情形下，请将 users 替换为一个计算属性 (比如 activeUsers)，让其返回过滤后的列表。

  2. 为了避免渲染本应该被隐藏的列表 (比如 v-for="user in users" v-if="shouldShowUsers")。这种情形下，请将 v-if 移动至容器元素上 (比如 ul、ol)

强烈推荐

组件一律使用单文件申明，而不是Vue.component

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

组件的文件名的格式要么都是PascalCase，要么都是是kebab-case

但单词大写开头对于代码编辑器的自动补全最为友好，因为这使得我们在 JS(X) 和模板中引用组件的方式尽可能的一致。然而，混用文件命名方式有的时候会导致大小写不敏感的文件系统的问题，这也是横线连接命名同样完全可取的原因。

基础组件名加特定前缀，比如 Base、App 或 V

应用特定样式和约定的基础组件 (也就是展示类的、无逻辑的或无状态的组件) 应该全部以一个特定的前缀开头，比如 Base、App 或 V。

好处：

  1. 当你在编辑器中以字母顺序排序时，你的应用的基础组件会全部列在一起，这样更容易识别。

  2. 因为组件名应该始终是多个单词，所以这样做可以避免你在包裹简单组件时随意选择前缀 (比如 MyButton、VueButton)。

  3. 因为这些组件会被频繁使用，所以你可能想把它们放到全局而不是在各处分别导入它们。使用相同的前缀可以让 webpack 这样工作：

var requireComponent = require.context("./src", true, /Base[A-Z]\w+\.(vue|js)$/)
requireComponent.keys().forEach(function (fileName) {
  var baseComponentConfig = requireComponent(fileName)
  baseComponentConfig = baseComponentConfig.default || baseComponentConfig
  var baseComponentName = baseComponentConfig.name || (
    fileName
      .replace(/^.+\//, '')
      .replace(/\.\w+$/, '')
  )
  Vue.component(baseComponentName, baseComponentConfig)
})

每个页面只能使用一次的组件应该以 The 前缀命名，以示其唯一性

这不意味着组件只可用于一个单页面，而是每个页面只使用一次。这些组件永远不接受任何 prop，因为它们是为你的应用定制的，而不是它们在你的应用中的上下文。如果你发现有必要添加 prop，那就表明这实际上是一个可复用的组件，只是目前在每个页面里只使用一次

紧密耦合的组件名依次加父组件前缀

如果一个组件只在某个父组件的场景下有意义，这层关系应该体现在其名字上。因为编辑器通常会按字母顺序组织文件，所以这样做可以把相关联的文件排在一起。不推荐文件夹嵌套。

components/
|- TodoList.vue
|- TodoListItem.vue
|- TodoListItemButton.vue

组件名中的单词顺序尽量让相关的在一起

给组件命名时并不需要遵从自然语言。

components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputExcludeGlob.vue
|- SearchInputQuery.vue
|- SettingsCheckboxLaunchOnStartup.vue
|- SettingsCheckboxTerms.vue

// 而不是下面的，这样翻找很困难
components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue

好处：

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

模板中组件名始终 kebab-case，<my-component></my-component>

对于绝大多数项目来说，在单文件组件和字符串模板中组件名应该总是 PascalCase 的——但是在 DOM 模板中总是 kebab-case 的。

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

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

声明 prop的时候用 camelCase，在模板和 JSX 中用 kebab-case

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

props: {
  greetingText: String
}

<welcome-message greeting-text="hi"></welcome-message>

多个 attribute 的元素,每个 attribute 一行

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

模板中只能用简单表达式，复杂的用computed

复杂表达式会让你的模板变得不那么声明式。我们应该尽量描述应该出现的是什么，而非如何计算那个值。而且计算属性和方法使得代码可以重用。

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

好处：

  • 易于测试。当每个计算属性都包含一个非常简单且很少依赖的表达式时，撰写测试以确保其正确工作就会更加容易。

  • 易于阅读。简化计算属性要求你为每一个值都起一个描述性的名称，即便它不可复用。这使得其他开发者 (以及未来的你) 更容易专注在他们关心的代码上并搞清楚发生了什么。

  • 更好的“拥抱变化”。任何能够命名的值都可能用在视图上。举个例子，我们可能打算展示一个信息，告诉用户他们存了多少钱；也可能打算计算税费，但是可能会分开展现，而不是作为总价的一部分。

小的、专注的计算属性减少了信息使用时的假设性限制，所以需求变更时也用不着那么多重构了

attribute 值尽量都带引号

在 HTML 中不带空格的 attribute 值是可以没有引号的，但这鼓励了大家在特征值里不写空格，导致可读性变差

指令缩写要么都用，要么都不用

指令缩写 (用 : 表示 v-bind:、用 @ 表示 v-on: 和用 # 表示 v-slot:) 应该要么都用要么都不用。

推荐

组件中选项的顺序

  • el
  • name
  • components/directives/filters
  • mixins/extends
  • props
  • data
  • computed
  • watch
  • created之类的生命周期钩子
  • methods
  • template

属性顺序

  • is
  • v-for
  • v-if/v-show
  • v-pre/v-once
  • id
  • ref
  • key
  • v-model
  • 其他
  • v-on
  • v-html/v-text

组件中顶级元素的顺序保持一致

template/script/style

谨慎

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

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

scoped 中的避免元素选择器，而尽量用类选择器

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

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

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

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

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

通过 this.$root 和/或全局事件总线管理状态在很多简单的情况下都是很方便的，但是并不适用于绝大多数的应用。

Vuex 是 Vue 的官方类 flux 实现，其提供的不仅是一个管理状态的中心区域，还是组织、追踪和调试状态变更的好工具。它很好地集成在了 Vue 生态系统之中 (包括完整的 Vue DevTools 支持)

avatar
文章
阅读
粉丝