Vue官方推荐的风格指南

Vue官方推荐的风格指南-我的笔记

最近刚注意到vue官方多了一个vue风格指南的推荐。

由于业务中一直用的vue，因此梳理学习一下，来增长本身代码的规范性，效果不错也能够安利到团队。

文档没有对JS或者HTML风格作约束，而是仅仅针对vue代码作了分类推荐。

一共按照优先级分4类：

• 优先级A：必要的。为了规避错误，这种代码风格是必须的
• 优先级B：强烈推荐。增长项目的可读性和开发体验
• 优先级C：推荐。有时可能同时有几种不错的选择。须要注意：先后一致、理由充分
• 优先级D：谨慎使用。为了该有潜在风险的代码敲个警钟。

为何写这篇文文章？

对我来讲有2个目的，

• 一是经过思惟导图 + 博客输出的方式加深印象

• 二是学习过程当中具体的小问题，应该用本身的话试着再解释一遍。

  • 好比Vue组须要有css做用域。可是scoped和css module有什么区别吗？
  • 好比v-for和v-if为何不推荐绑定在一个元素上？

1.优先级A的code style

这些推荐，必须遵照。若是不这么作，基本要形成性能低或可维护性差的问题

• 1.vue组件名称推荐由多个单词构成
• 2.组件data数据推荐用函数return
• 3.props推荐更加详细的定义type/default/require等
• 4.v-for推荐有配套的:key
• 5.v-for和v-if避免同在一块儿
• 6.vue组件样式推荐设置做用域
• 7.自定义的私有属性，推荐$_ + 命名空间做为前缀

下面是每一条风格指南的推荐理由，我以为须要在乎的，用粗体标注

1.vue组件名称推荐由多个单词构成

为了不vue组件名和将来html元素的名称重复。由于html的标签都是单个单词

2.组件data数据推荐用函数return

除了根组件以外，其余的vue组件极可能被复用，若是data是{},那么这些组件的数据会互相影响。

可是咱们但愿每个组件，即使是被复用的组件，每一个组件的data都应该是独立的状态

3.props推荐用更加详细的定义

//很好理解，详细的约定确定比简写的约定更可靠。

props: {                     // 推荐
    name : {
        type: String,
        default: 'ziwei',
        required: true
    }
}

props: ['name']              // 不推荐

4.v-for推荐配套的:key

为了更加高效的渲染dom。vue有“就地复用”的策略。

好比一个列表的数据没变，只是顺序发生了改变。若是全部列表的dom从新渲染就很“浪费”

可是经过惟一的:key复用以前的dom的话，性能就好不少。

5.v-for和v-if避免使用在同一个组件里

这里推荐看文档，例子和解释都很清晰。v-for和v-if同时出现的话，先v-for，后v-if

有v-for和v-if同时写到li上的状况有2种：

- 若是是但愿控制ul的显示/隐藏，推荐放到ul上，而不是li上。这样“节省”了li的渲染
- 若是是由于根据条件控制部分li的显示/隐藏，建议用把ul数据对象改为计算属性。

6.vue组件样式推荐设置做用域

可使用scoped和css module。可是二者仍是有一些区别的。

scoped被设计的初衷是不能让当前组件的样式，影响其余组件的样式。因此你写组件库，不要用scoped

css moudle是利用命名空间和hash来保证做用域

关于二者区别的连接

https://juejin.im/post/5a1c06...
https://www.jb51.net/article/...

关于css选择器对渲染性能的影响

https://www.jianshu.com/p/268...

7.自定义的私有属性，推荐$_ + 命名空间做为前缀

我理解这里，就是若是你要第三方插件或者，要自定义vue属性时。

vue给你推荐了一种命名空间，好比这样定义 $_myUtils_sayHi

优先级B的code style

• 1.能用.vue写的组件，尽可能不一样vue.component
• 2.vue组件命名，用PascalCase或者短横线，风格保持统一。
• 3.基础组件命名，以Base前缀开头，以显示其通用性
• 4.单例组件命名，以The前缀开头，以显示其独特性
• 5.紧密耦合的组件命名。好比紧密耦合的父子组件，子组件以父组件名称为前缀
• 6.组件命名单词的顺序。先名词后形容词
• 7.自闭合组件的写法。若是有编译器的vue用自闭合写法，以显示没有传入属性
• 8.不一样模板中vue命名大小写。若是有编译器的话PascalCase,不然用短横线命名
• 9.JS/JSX中始终用PascalCase组件命名
• 10.组件命名单词应该是完整的单词
• 11.props的命名方式，最天然的方法。JS里用驼峰命名，html里用短横线
• 12.vue组件有多个属性，分多行来写更加清晰易读
• 13.模板里复杂逻辑用计算属性或者method
• 14.复杂的计算属性或者method，拆分红多个
• 15.html模板的属性推荐用双引号的
• 16.指令缩写要么不写，要么都用缩写

下面是每一条风格指南的推荐理由,我以为须要在乎的，用粗体标注

1.能用.vue写的组件，尽可能不一样vue.component

好理解，vue单文件组织代码，是官方推荐的最佳实践，基本都是这样用

2.vue组件名称，用PascalCase或者短横线，风格保持统一

这个能够注意下，PascalCase是相似OrderSku.vue这种命名风格

我以前常常用驼峰命名vue组件

3.基础组件命名，以Base前缀开头，以显示其通用性

BaseHeader.vue
BaseContent.vue
BaseFooter.vue
// 这类风格，经过名字，能够理解它是通用基础组件

4.单例组件命名，以The前缀开头，以显示其独特性

相似设计模式里的单例模式，就是这个vue组件只在一个页面出现一次。

TheSideBar.vue这种名字，能够表示它是独一无二的不可复用的组件

若是某个组件只是在每一个页面最多用了一次，而且没有props。就是不可复用组件，用The前缀命名。

5.紧密耦合的组件命名。好比紧密耦合的父子组件，子组件以父组件名称为前缀

MainOrder.vue
MainOrderItem.vue

// 相似这种紧密耦合的父子组件，子组件把父组件的名字做为前缀。
// 这样这样能够经过名称，显示他们的耦合关系，而且在编辑器里也很好找到

6.组件命名单词的顺序。先名词后形容词

|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue

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

// 大概能够感觉到吧，我理解是由于编辑器的默认排序是按照字母排序。这样方便咱们找到类似的文件

7.自闭合组件的写法。

<App />
自闭合组件是vue推荐的写法。自闭合能够表示组件没有任何属性

可是若是你用的是没有编译器的vue版本，也就是不用.vue的话，那么html里不支持自定义属性的自闭合写法。
因此这种状况下，只能用短横线写法

8.不一样模板中vue命名大小写。若是有编译器的话PascalCase,不然用短横线命名

相似的，SkuOrder.vue这类PascalCase命名规则是vue推荐的

可是若是是没有编译器的vue版本，在html里大小写不敏感，你只能用短横线命名。

9.JS/JSX中始终用PascalCase组件命名

由于官方推荐PascalCase风格命名，因此能用就用

10.组件命名单词应该是完整的单词

完整单词带易读性的好处，和书写麻烦的缺点。

可是编辑器的智能提示已经解决了写长单词的麻烦了,因此仍是推荐用完整单词

11.props的命名方式

props: {
  greetingText: String
}
<WelcomeMessage greeting-text="hi"/>

最天然的方法。JS里用驼峰命名，html里用短横线。这个要注意，我以前很随意

12.vue组件有多个属性，分多行来写更加清晰易读

<MyComponent
  foo="a"
  bar="b"
  baz="c"
/>
好理解，分多行写的话易读性更强，这个我以前没注意

13.模板里复杂逻辑用计算属性或者method (很好理解，就不解释了)
14.复杂的计算属性或者method，拆分红多个 (很好理解，就不解释了)

15.html模板的属性推荐用双引号的

这个注意下，我以前很不喜欢在html里写“”，由于我以为双引号容易让人误觉得是string

可是官方推荐用引号，说是在有空格的状况下，可能缩进不正常，影响易读性。因此乖乖听话就完事了

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

注意保持风格统一，要么不写，要么都写

3.优先级C的code style （推荐看文档）

推荐看文档，由于文档推荐了顺序，可是大部分选型我都不经常使用，因此我只给本身经常使用的的选项排序

• 1.组件实例选项的顺序
• 2.元素特性的顺序
• 3.组件实例选项，之间添加一个空行
• 4.单文件组件的顶级元素的组织顺序

1.组件实例选项的顺序

- components
- filters
- data
- compouted
- watch
- 全部的生命周期钩子
- methods

2.元素特性的顺序

- v-for
- v-if / v-show
- id
- ref / key / slot
- v-model
- v-on

3.组件实例选项之间，建议加一个空格

4.单文件组件，顶级元素的顺序

<template>
<script>
<style>

按照这个顺序组织代码就能够。注意style只能在最下面，script和template至少要有一个

4.优先级D的，须要慎用code style （推荐看文档）

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

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

• scoped 中的元素选择器

大量使用scoped里的元素 + 自定义属性选择器，性能会慢一些。

因此尽可能用class

• 隐性的父子组件通讯

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

• 非 Flux 的全局状态管理

没什么好说的，就是推荐用vuex，而不是eventbus,我以为仍是看具体状况