Vue开发规范细节

Posted 飞翔的熊blabla

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Vue开发规范细节相关的知识,希望对你有一定的参考价值。

转自于:https://blog.csdn.net/D321xiaoding/article/details/113783190

Vue开发规范细节

一、必要的
1、组件名为多个单词

组件名应该始终是多个单词的,根组件 App 以及 、 之类的 Vue 内置组件除外。

这样做可以避免跟现有的以及未来的 html 元素相冲突,因为所有的 HTML 元素名称都是单个单词的。

例如:

Vue.component(‘todo-item’, {
// …
})
export default { name: ‘TodoItem’, // … }

2、组件数据

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

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

例如:

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’ } })

3、Prop 定义

Prop 定义应该尽量详细。

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

例如:

props: {
status: String
}
// 更好的做法! props: { status: { type: String, required: true, default: ‘’, } }

4、为 v-for 设置键值

总是用 key 配合 v-for。

在组件上总是必须用 key 配合 v-for,以便维护内部组件及其子树的状态。甚至在元素上维护可预测的行为,比如动画中的对象固化 (object constancy),也是一种好的做法。

例如:

{{ todo.text }}
5、避免 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)。

例如:

{{ user.name }}
{{ user.name }}
6、为组件样式设置作用域

对于应用来说,顶级 App 组件和布局组件中的样式可以是全局的,但是其它所有组件都应该是有作用域的。

这条规则只和单文件组件有关。你不一定要使用 scoped attribute。设置作用域也可以通过 CSS Modules,那是一个基于 class 的类似 BEM 的策略,当然你也可以使用其它的库或约定。

不管怎样,对于组件库,我们应该更倾向于选用基于 class 的策略而不是 scoped attribute。

这让覆写内部样式更容易:使用了常人可理解的 class 名称且没有太高的选择器优先级,而且不太会导致冲突。

例如:

X

8、模板中的组件名大小写

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

PascalCase 相比 kebab-case 有一些优势:

编辑器可以在模板里自动补全组件名,因为 PascalCase 同样适用于 javascript
视觉上比 更能够和单个单词的 HTML 元素区别开来,因为前者的不同之处有两个大写字母,后者只有一个横线。
如果你在模板中使用任何非 Vue 的自定义元素,比如一个 Web Component,PascalCase 确保了你的 Vue 组件在视觉上仍然是易识别的。
不幸的是,由于 HTML 是大小写不敏感的,在 DOM 模板中必须仍使用 kebab-case。

还请注意,如果你已经是 kebab-case 的重度用户,那么与 HTML 保持一致的命名约定且在多个项目中保持相同的大小写规则就可能比上述优势更为重要了。在这些情况下,在所有的地方都使用 kebab-case 同样是可以接受的。

例如:

或者
9、JS/JSX 中的组件名大小写

JS/JSX 中的组件名应该始终是 PascalCase 的,尽管在较为简单的应用中只使用 Vue.component 进行全局组件注册时,可以使用 kebab-case 字符串。

例如:
Vue.component(‘MyComponent’, {
// …
})
Vue.component(‘my-component’, {
// …
})
import MyComponent from ‘./MyComponent.vue’
export default { name: ‘MyComponent’, // … }

10、完整单词的组件名

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

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

例如:

components/

|- StudentDashboardSettings.vue

|- UserProfileOptions.vue

11、Prop 名大小写

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

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

例如:

props: {
greetingText: String
}
12、多个 attribute 的元素

多个 attribute 的元素应该分多行撰写,每个 attribute 一行。

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

例如:

src=“https://vuejs.org/images/logo.png”
alt=“Vue Logo”

13、模板中简单的表达式

组件模板应该只包含简单的表达式,复杂的表达式则应该重构为计算属性或方法。

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

例如:

{{ normalizedFullName }}
// 复杂表达式已经移入一个计算属性 computed: { normalizedFullName: function () { return this.fullName.split(’ ‘).map(function (word) { return word[0].toUpperCase() + word.slice(1) }).join(’ ') } }

14、简单的计算属性

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

computed: {
basePrice: function () {
return this.manufactureCost / (1 - this.profitMargin)
},
discount: function () {
return this.basePrice * (this.discountPercent || 0)
},
finalPrice: function () {
return this.basePrice - this.discount
}
}

15、带引号的 attribute 值

非空 HTML attribute 值应该始终带引号 (单引号或双引号,选你 JS 里不用的那个)。

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

例如:

16、指令缩写

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

:value=“newTodoText”
:placeholder=“newTodoInstructions”

v-bind:value=“newTodoText”
v-bind:placeholder=“newTodoInstructions”

@input=“onInput”
@focus=“onFocus”

v-on:input=“onInput”
v-on:focus=“onFocus”

Here might be a page title
Here's some contact info

三、推荐的

1、组件/实例的选项的顺序

组件/实例的选项应该有统一的顺序。

这是我们推荐的组件选项默认顺序。它们被划分为几大类,所以你也能知道从插件里添加的新 property 应该放到哪里。

副作用 (触发组件外的影响)

el
全局感知 (要求组件以外的知识)

name
parent
组件类型 (更改组件的类型)

functional
模板修改器 (改变模板的编译方式)

delimiters
comments
模板依赖 (模板内使用的资源)

components
directives
filters
组合 (向选项里合并 property)

extends
mixins
接口 (组件的接口)

inheritAttrs
model
props/propsData
本地状态 (本地的响应式 property)

data
computed
事件 (通过响应式事件触发的回调)

watch
生命周期钩子 (按照它们被调用的顺序)
beforeCreate
created
beforeMount
mounted
beforeUpdate
updated
activated
deactivated
beforeDestroy
destroyed
非响应式的 property (不依赖响应系统的实例 property)

methods
渲染 (组件输出的声明式描述)

template/render
renderError
2、元素 attribute 的顺序

元素 (包括组件) 的 attribute 应该有统一的顺序。

这是我们为组件选项推荐的默认顺序。它们被划分为几大类,所以你也能知道新添加的自定义 attribute 和指令应该放到哪里。

定义 (提供组件的选项)

is
列表渲染 (创建多个变化的相同元素)

v-for
条件渲染 (元素是否渲染/显示)

v-if
v-else-if
v-else
v-show
v-cloak
渲染方式 (改变元素的渲染方式)

v-pre
v-once
全局感知 (需要超越组件的知识)

id
唯一的 attribute (需要唯一值的 attribute)

ref
key
双向绑定 (把绑定和事件结合起来)

v-model
其它 attribute (所有普通的绑定或未绑定的 attribute)

事件 (组件事件监听器)

v-on
内容 (覆写元素的内容)

v-html
v-text
3、组件/实例选项中的空行

你可能想在多个 property 之间增加一个空行,特别是在这些选项一屏放不下,需要滚动才能都看到的时候。

当你的组件开始觉得密集或难以阅读时,在多个 property 之间添加空行可以让其变得容易。在一些诸如 Vim 的编辑器里,这样格式化后的选项还能通过键盘被快速导航。

例如:

props: {
value: {
type: String,
required: true
},

  focused: {
    type: Boolean,
    default: false
  },

  label: String,
  icon: String
},

computed: {
  formattedValue: function () {
    // ...
  },

  inputClasses: function () {
    // ...
  }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
}

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

单文件组件应该总是让

...


————————————————
版权声明:本文为CSDN博主「相约在一年四季」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/D321xiaoding/article/details/113783190

以上是关于Vue开发规范细节的主要内容,如果未能解决你的问题,请参考以下文章

Vue前端开发规范简介

vue开发规范

团队开发前端VUE项目代码规范

后端开发者的Vue学习之路

Vue开发规范

vue项目中开发规范记录