What are the specifications for Vue front-end development?

This time I will bring you what are the specifications for Vue front-end development, what are the precautions of Vue front-end development specifications, the following is a practical case, let's take a look.

Based on Vue official style guide

1. Mandatory

1. The component name must be multiple words

Component names should always be multiple words, except for the root component App.

Positive example:

export default {
 name: 'TodoItem',
 // ...
}
反例：
export default {
 name: 'Todo',
 // ...
}

2. Component data

The data of the component must be a function.

When using the data attribute in a component (anywhere except new Vue), its value must be a function that returns an object.

Positive example:

// In a .vue file
export default {
 data () {
 return {
 foo: 'bar'
 }
 }
}
// 在一个 Vue 的根实例上直接使用对象是可以的，
// 因为只存在一个这样的实例。
new Vue({
 data: {
 foo: 'bar'
 }
})

Counterexample:

export default {
 data: {
 foo: 'bar'
 }
}

3. Prop definition

Prop definition should be as detailed as possible.

In the code you submit, the definition of prop should be as detailed as possible, at least specifying its type.

Positive example:

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

Counter example:

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

4. Set the key value for v-for

Always use key with v-for.

Key must always be used with v-for on components to maintain the state of internal components and their subtrees. Even maintaining predictable behavior on elements, such as object constancy in animations, is a good practice.

Positive example:

<ul>
 <li
 v-for="todo in todos"
 :key="todo.id"
 >
 {{ todo.text }}
 </li>
</ul>

Counterexample:

<ul>
 <li v-for="todo in todos">
 {{ todo.text }}
 </li>
</ul>

5. Avoid using v-if and v-for together

Never use v-if and v-for are used on the same element at the same time.

Generally we tend to do this in two common situations:

In order to filter items in a list (such as v-for="user in users" v- if="user.isActive"). In this case, replace users with a computed property (such as activeUsers) that returns the filtered list.

To avoid rendering lists that should be hidden (e.g. v-for="user in users" v-if="shouldShowUsers"). In this case, move v-if to the container element (e.g. ul, ol).

Positive example:

<ul v-if="shouldShowUsers">
 <li
 v-for="user in users"
 :key="user.id"
 >
 {{ user.name }}
 </li>
</ul>

Counter example:

<ul>
 <li
 v-for="user in users"
 v-if="shouldShowUsers"
 :key="user.id"
 >
 {{ user.name }}
 </li>
</ul>

6. Set scope for component style

For applications, top-level App components and layout components Styles in can be global, but all other components should be scoped.

This rule is only relevant for single-file components. You don't have to use the scoped attribute. Setting scope can also be done through CSS Modules, which is a class-based strategy similar to BEM, but of course you can also use other libraries or conventions.

In any case, for component libraries, we should prefer a class-based strategy rather than scoped features.

This makes it easier to override internal styles: human-readable class names are used without high selector precedence, and are less likely to cause conflicts.

Positive example:

<template>
 <button class="c-Button c-Button--close">X</button>
</template>
<!-- 使用 BEM 约定 -->
<style>
.c-Button {
 border: none;
 border-radius: 2px;
}
.c-Button--close {
 background-color: red;
}
</style>

Counterexample:

<template>
 <button class="btn btn-close">X</button>
</template>
<style>
.btn-close {
 background-color: red;
}
</style>
<template>
 <button class="button button-close">X</button>
</template>
<!-- 使用 `scoped` 特性 -->
<style scoped>
.button {
 border: none;
 border-radius: 2px;
}
.button-close {
 background-color: red;
}
</style>

2. Strongly recommended (enhance readability)

1. Component files

As long as there is a build system that can splice files, separate each component into separate files.
When you need to edit a component or check the usage of a component, you can find it more quickly.

Positive example:

components/
|- TodoList.vue
|- TodoItem.vue

Counter example:

V
ue.component('TodoList', {
 // ...
})
Vue.component('TodoItem', {
 // ...
})

2. The case of single-file component files

The file name of a single-file component should always be either Words start with capital letters (PascalCase)

Positive example:

components/
|- MyComponent.vue

Counter example:

components/
|- myComponent.vue
|- mycomponent.vue

3. Basic component name

Basic component that applies specific styles and conventions (i.e. presentational, non-logical or stateless components) should all start with a specific prefix, such as Base, App or V.

Positive example:

components/
|- BaseButton.vue
|- BaseTable.vue
|- BaseIcon.vue

Counter example:

components/
|- MyButton.vue
|- VueTable.vue
|- Icon.vue

4. Singleton component name

Components that should only have a single active instance should be named with the prefix , to show its uniqueness.

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

正例：

components/
|- TheHeading.vue
|- TheSidebar.vue

反例：

components/
|- Heading.vue
|- MySidebar.vue

5. 紧密耦合的组件名

和父组件紧密耦合的子组件应该以父组件名作为前缀命名。

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

正例：

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

反例：

components/
|- SearchSidebar.vue
|- NavigationForSearchSidebar.vue

6. 组件名中的单词顺序

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

正例：

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

反例：

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

7. 模板中的组件名大小写

总是 PascalCase 的

正例：

<!-- 在单文件组件和字符串模板中 -->
<MyComponent/>

反例：

<!-- 在单文件组件和字符串模板中 -->
<mycomponent/>
<!-- 在单文件组件和字符串模板中 -->
<myComponent/>

8. 完整单词的组件名

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

正例：

components/
|- StudentDashboardSettings.vue
|- UserProfileOptions.vue

反例：

components/
|- SdSettings.vue
|- UProfOpts.vue

9. 多个特性的元素

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

正例：

<img
 src="https://vuejs.org/images/logo.png"
 alt="Vue Logo"
>
<MyComponent
 foo="a"
 bar="b"
 baz="c"
/>

反例：

<img src="https://vuejs.org/images/logo.png" alt="Vue Logo">
<MyComponent foo="a" bar="b" baz="c"/>

10. 模板中简单的表达式

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

正例：

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

反例：

{{
 fullName.split(' ').map(function (word) {
 return word[0].toUpperCase() + word.slice(1)
 }).join(' ')
}}

11. 简单的计算属性

正例：

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

反例：

computed: {
 price: function () {
 var basePrice = this.manufactureCost / (1 - this.profitMargin)
 return (
 basePrice -
 basePrice * (this.discountPercent || 0)
 )
 }
}

12. 带引号的特性值

非空 HTML 特性值应该始终带引号 (单引号或双引号，选你 JS 里不用的那个)。
在 HTML 中不带空格的特性值是可以没有引号的，但这样做常常导致带空格的特征值被回避，导致其可读性变差。

正例：

<AppSidebar :style="{ width: sidebarWidth + &#39;px&#39; }">

反例：

<AppSidebar :style={width:sidebarWidth+&#39;px&#39;}>

13. 指令缩写

都用指令缩写 (用 : 表示 v-bind: 和用 @ 表示 v-on:)

正例：

<input
 @input="onInput"
 @focus="onFocus"
>

反例：

<input
 v-bind:value="newTodoText"
 :placeholder="newTodoInstructions"
>

三、推荐

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

单文件组件应该总是让