隨著 VueJS 的使用越來越廣泛，出現了幾種最佳實踐並逐漸成為標準。在本文中，主要分享在平時開發中一些有用資源和技巧，廢話少說，我們開始吧。
1.始終在 v-for 中使用 :key
在需要操縱數據時，將key屬性與v-for指令一起使用可以讓程序保持恆定且可預測。
這是很有必要的，這樣Vue就可以跟蹤組件狀態，並對不同的元素有一個常量引用。在使用動畫或Vue轉換時，key 非常有用。
如果沒有key ，Vue只會嘗試使DOM儘可能高效。 這可能意味著v-for中的元素可能會出現亂序，或者它們的行為難以預測。 如果我們對每個元素都有唯一的鍵引用，那麼我們可以更好地預測Vue應用程序將如何精確地處理DOM操作。
<code>/<code>
複製代碼在事件中使用短橫線命名
在發出定製事件時，最好使用短橫線命名，這是因為在父組件中，我們使用相同的語法來偵聽該事件。
因此，為了確保我們各組件之間的一致性，並使您的代碼更具可讀性，請在兩個地方都堅持使用短橫線命名。
<code>this.$emit('close-window')
// 在父組件中
<popup-window>
複製代碼/<code>3.使用駝峰式聲明 props，並在模板中使用短橫線命名來訪問 props
最佳做法只是遵循每種語言的約定。 在 JS 中，駝峰式聲明是標準，在HTML中，是短橫線命名。 因此，我們相應地使用它們。
幸運的是，Vue 已經提供了駝峰式聲明和短橫線命名之間轉換，因此除了實際聲明它們之外，我們不必擔心任何事情。
<code>// 不好的做法
<popupwindow>
props: { 'title-text': String }
// 好的做法
<popupwindow>
props: { titleText: String }
複製代碼/<code>4.data 應始終返回一個函數
聲明組件data時，data選項應始終返回一個函數。 如果返回的是一個對象，那麼該data將在組件的所有實例之間共享。
<code>// 不好的做法
data: {
name: 'My Window',
articles: []
}
複製代碼/<code>但是，大多數情況下，我們的目標是構建可重用的組件，因此我們希望每個組件返回一個惟一的對象。我們通過在函數中返回數據對象來實現這一點。
<code>// 好的做法
data () {
return {
name: 'My Window',
articles: []
}
}
複製代碼/<code>5. 不要在同個元素上同時使用v-if和v-for指令
為了過濾數組中的元素，我們很容易將v-if與v-for在同個元素同時使用。
<code>// 不好的做法/<code>
複製代碼問題是在 Vue 優先使用v-for指令，而不是v-if指令。它循環遍歷每個元素，然後檢查v-if條件。
<code>this.products.map(function (product) {
if (product.price < 500) {
return product
}
})
複製代碼/<code>這意味著，即使我們只想渲染列表中的幾個元素，也必須遍歷整個數組。
這對我們來當然沒有任何好處。
一個更聰明的解決方案是遍歷一個計算屬性，可以把上面的例子重構成下面這樣的：
<code>/<code>
computed: {
cheapProducts: () => {
return this.products.filter(function (product) {
return product.price < 100
})
}
}
複製代碼這麼做有幾個好處：
- 渲染效率更高，因為我們不會遍歷所有元素
- 僅當依賴項更改時，才會重使用過濾後的列表
- 這寫法有助於將組件邏輯從模板中分離出來，使組件更具可讀性
6.用正確的定義驗證我們的 props
可以這條是很重要，為什麼？
在設計大型項目時，很容易忘記用於props的確切格式、類型和其他約定。如果你在一個更大的開發團隊中，你的同事不會讀心術，所以你要清楚地告訴他們如何使用你的組件。
因此，我們只需編寫props驗證即可，不必費力地跟蹤組件來確定props的格式
從Vue文檔中查看此示例。
<code>props: {
status: {
type: String,
required: true,
validator: function (value) {
return [
'syncing',
'synced',
'version-conflict',
'error'
].indexOf(value) !== -1
}
}
}
複製代碼/<code>7.組件全名使用駝峰或或者短橫線
組件的通用命名約定是使用駝峰或短橫線。無論我們使用哪咱，最重要的是始終保持一致。我認為駝峰方式 效果最好，因為大多數IDE自動完成功能都支持它。
<code># 不好的做法
mycomponent.vue
myComponent.vue
Mycomponent.vue
# 好做法
MyComponent.vue
複製代碼/<code>8. 基本組件應該相應地加上前綴
根據Vue樣式指南，基本組件是僅包含以下內容的組件：
- HTML 元素
- 額外的基礎組件
- 第三方的UI組件
為這些組件命名的最佳實踐是為它們提供前綴Base、V或App。同樣，只要我們在整個項目中保持一致，可以使用其中任何一種。
<code>BaseButton.vue
BaseIcon.vue
BaseHeading.vue
複製代碼/<code>該命名約定的目的是使基本組件按字母順序分組在文件系統中。 另外，通過使用webpack導入功能，我們可以搜索與命名約定模式匹配的組件，並將所有組件自動導入為Vue項目中的全局變量。
單實例組件命名應該帶有前綴 The
與基本組件類似，單實例組件(每個頁面使用一次，不接受任何prop)應該有自己的命名約定。這些組件特定於我們的應用，通常是 footer，header或sider。
該組件只能有一個激活實例。
<code>TheHeader.vue
TheFooter.vue
TheSidebar.vue
ThePopup.vue
複製代碼/<code>10.保持指令簡寫的一致性
在Vue開發人員中，一種常見的技術是使用指令的簡寫。例如：
- @是v-on的簡寫
- : 是 v-bind 的簡寫
- # 是 v-slot 的簡寫
在你的Vue項目中使用這些縮寫是很好的。但是要在整個項目中創建某種約定，總是使用它們或從不使用它們,會使我們的項目更具內聚性和可讀性。
11.不要在“created”和“watch”中調用方法
Vue開發人員經常犯的一個錯誤是他們不必要地在created和watch中調用方法。 其背後的想法是，我們希望在組件初始化後立即運行watch。
// 不好的做法 created: () { this.handleChange() }, methods: { handleChange() { // stuff happens } }, watch () { property() { this.handleChange() } }
但是，Vue為此提供了內置的解決方案，這是我們經常忘記的Vue watch屬性。
我們要做的就是稍微重組watch並聲明兩個屬性：
1.handler (newVal, oldVal)-這是我們的watch方法本身。 2. immediate: true- 代表如果在 wacth 裡聲明瞭之後，就會立即先去執行裡面的handler方法，如果為 false就跟我們以前的效果一樣，不會在綁定的時候就執行
<code>// 好的做法
methods: {
handleChange() {
// stuff happens
}
},
watch () {
property {
immediate: true
handler() {
this.handleChange()
}
}
}
複製代碼/<code>12. 模板表達式應該只有基本的 JS 表達式
在模板中添加儘可能多的內聯功能是很自然的。但是這使得我們的模板不那麼具有聲明性，而且更加複雜，也讓模板會變得非常混亂。
為此，讓我們看看Vue樣式指南中另一個規範化字符串的示例，看看它有多混亂。
<code>//不好的做法
{{
fullName.split(' ').map(function (word) {
return word[0].toUpperCase() + word.slice(1)
}).join(' ')
}}
複製代碼/<code>基本上，我們希望模板中的所有內容都直觀明瞭。 為了保持這一點，我們應該將複雜的表達式重構為適當命名的組件選項。
分離複雜表達式的另一個好處是可以重用這些值。
<code>// 好的做法
{{ normalizedFullName }}
// The complex expression has been moved to a computed property
computed: {
normalizedFullName: function () {
return this.fullName.split(' ').map(function (word) {
return word[0].toUpperCase() + word.slice(1)
}).join(' ')
}
}
複製代碼/<code>總結
這是12個最常見的最佳實踐，它們將使我們的Vue代碼更易於維護、可讀性更好、更專業。希望這些技巧對您有用（因為它們絕對是我一直想記住的東西）。
"
閱讀更多 Echa攻城獅 的文章
