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,我以爲仍是看具體狀況