前言
vue之火，不言而喻，框架給前端帶來了方便，但是程式碼的漏洞也會很多。如果不加以注意和優化就會陷入不必要的效能、冗餘等問題，所以我們有必要關注優化的重要性，下面我們將把常用的優化做一些總結和探索 我們將從以下幾方面著手
優化方向
最佳實踐
一、程式碼優化方向
技術選型沒有最好的，只有最適合業務的。目前我們的業務是用gulp+webpack打包構建的。目前有幾個痛點：
1、程式碼冗餘。
我們經常引入了一個大的utils庫，實際上只是引用了這個庫中的一個方法，但是卻打包了整個庫，程式碼的冗餘和浪費。隨著引入的檔案越來越多，這種問題也會變得越來越明顯。無論是基於程式碼潔癖，還是程式碼體積來看，都有優化的必要。
2、非同步流程控制。
隨著JS前端的發展，我們站著大牛的肩膀上，逐步擺脫了回撥地獄，以及各種非同步流程的坑。有著目前來看最好的非同步流程解決方案「async/await方案」。Node 7.6版本已經正式支援了此特性，Browser端也可以統一，達到前後端同構的目的。清晰的非同步流程控制對於團隊程式碼的理解和維護都有著積極的意義。
3、程式碼潔癖的考慮。
引入箭頭函式，簡化程式碼。利用箭頭函式不繫結this的特性，解決this「漂移」問題。
二、基礎優化
所謂的基礎優化是任何 web 專案都要做的，並且是問題的根源。HTML，CSS，JS 是第一步要優化的點
分別對應到 .vue 檔案內的，<template>,<style>,<script>，下面逐個談下 vue 專案裡都有哪些值得優化的點
template
語義化標籤，避免亂巢狀，合理命名屬性等等標準推薦的東西就不談了。
模板部分幫助我們展示結構化資料，vue 通過資料驅動檢視，主要注意一下幾點
v-show，v-if 用哪個？
在我來看要分兩個維度去思考問題：
- 第一個維度是許可權問題，只要涉及到許可權相關的展示無疑要用 v-if*
- 第二個維度在沒有許可權限制下根據使用者點選的頻次選擇，頻繁切換的使用 v-show，不頻繁切換的使用 v-if
這裡要說的優化點在於減少頁面中 dom 總數，我比較傾向於使用 v-if，因為減少了 dom 數量，加快首屏渲染，至於效能方面我感覺肉眼看不出來切換的渲染過程，也不會影響使用者的體驗。
不要在模板裡面寫過多的表示式與判斷 v-if="isShow && isAdmin && (a || b)"，這種表示式雖說可以識別，但是不是長久之計，當看著不舒服時，適當的寫到 methods 和 computed 裡面封裝成一個方法，這樣的好處是方便我們在多處判斷相同的表示式，其他許可權相同的元素再判斷展示的時候呼叫同一個方法即可。
迴圈呼叫子元件時新增 key，key 可以唯一標識一個迴圈個體，可以使用例如 item.id 作為 key，假如陣列資料是這樣的 ['a' , 'b', 'c', 'a'],使用 :key="item" 顯然沒有意義，更好的辦法就是在迴圈的時候 (item, index) in arr，然後 :key="index"來確保 key 的唯一性。
style
將樣式檔案放在 vue 檔案內還是外？討論起來沒有意義，重點是按模組劃分，我的習慣是放在 vue 檔案內部，方便寫程式碼是在同一個檔案裡跳轉上下對照，無論內外建議加上 <style scopeed> 將樣式檔案鎖住，目的很簡單，再好用的標準也避免不了多人開發的麻煩，約定命名規則也可能會衝突，鎖定區域後儘量採用簡短的命名規則，不需要 .header-title__text 之類的 class，直接 .title 搞定。
為了和上一條作區分，說下全域性的樣式檔案，全域性的樣式檔案，儘量抽象化，既然不在每一個元件裡重複寫，就儘量通用，這部分抽象做的越好說明你的樣式檔案體積越小，複用率越高。建議將複寫元件庫如 Element 樣式的程式碼也放到全域性中去。
不使用 float 佈局，之前看到很多人封裝了 .fl -- float: left 到全域性檔案裡去，然後又要 .clear，現在的瀏覽器還不至於弱到非要用 float 去相容，完全可以 flex，grid 相容性一般，功能其實 flex 佈局都可以實現，float 會帶來佈局上的麻煩，用過的都知道不相信解釋坑了。
至於其他通用的規範這裡不贅述，相關文章很多。
script
這部分也是最難優化的點，說下個人意見吧。
多人開發時儘量保持每個元件 export default {} 內的方法順序一致，方便查詢對應的方法。我個人習慣 data、props、鉤子、watch、computed、components。
data 裡要說的就是初始化資料的結構儘量詳細，命名清晰，簡單易懂，避免無用的變數，isEditing 實際可以代表兩個狀態，true 或 false，不要再去定義 notEditing 來控制展示，完全可以在模板裡 {{ isEditing ? 編輯中 : 儲存 }}
props 父子元件傳值時儘量 :width="" :heigth="" 不要 :option={}，細化的好處是隻傳需要修改的引數，在子元件 props 里加資料型別，是否必傳，以及預設值，便於排查錯誤，讓傳值更嚴謹。
鉤子理解好生命週期的含義就好，什麼時間應該請求，什麼時間登出方法，哪些方法需要登出。簡單易懂，官網都有寫。
metheds 中每一個方法一定要簡單，只做一件事，儘量封裝可複用的簡短的方法，引數不易過多。如果十分依賴 lodash 開發，methed 看著會簡潔許多，代價就是整體的 bundle 體積會大，假如專案僅僅用到小部分方法可以區域性引入 loadsh，不想用 lodash 的話可以自己封裝一個 util.js 檔案
watch 和 computed 用哪個的問題看官網的例子，計算屬性主要是做一層 filter 轉換，切忌加一些呼叫方法進去，watch 的作用就是監聽資料變化去改變資料或觸發事件如 this.$store.dispatch('update', { ... })
三、元件優化
vue 的元件化深受大家喜愛，到底元件拆到什麼程度算是合理，還要因專案大小而異，小型專案可以簡單幾個元件搞定，甚至不用 vuex，axios 等等，如果規模較大就要細分元件，越細越好，包括佈局的封裝，按鈕，表單，提示框，輪播等，推薦看下 Element 元件庫的程式碼，沒時間寫這麼詳細可以直接用 Element 庫，分幾點進行優化
元件有明確含義，只處理類似的業務。複用性越高越好，配置性越強越好。
自己封裝元件還是遵循配置 props 細化的規則。
元件分類，我習慣性的按照三類劃分，page、page-item 和 layout，page 是路由控制的部分，page-item 屬於 page 裡各個佈局塊如 banner、side 等等，layout 裡放置多個頁面至少出現兩次的元件，如 icon, scrollTop 等
vue-router 和 vuex 優化 vue-router 除了切換路由，用的最多的是處理許可權的邏輯，關於許可權的控制這裡不贅述，相關 demo 和文章有許多，那麼說到優化，值得一提的就是元件懶載入
官網連結如上，例子如下
const Foo = r => require.ensure([], () => r(require('./Foo.vue')), 'group-foo')
const Bar = r => require.ensure([], () => r(require('./Bar.vue')), 'group-foo')
const Baz = r => require.ensure([], () => r(require('./Baz.vue')), 'group-foo')
複製程式碼這段程式碼將 Foo, Bar, Baz 三個元件打包進了名為 group-foo 的 chunk 檔案，當然啦是 js 檔案
其餘部分正常寫就可以，在網站載入時會自動解析需要載入哪個 chunk，雖然分別打包的總體積會變大，但是單看請求首屏速度的話，快了好多。
vuex 面臨的問題和解決方案有幾點
當網站足夠大時，一個狀態樹下，根的部分欄位繁多，解決這個問題就要模組化 vuex，官網提供了模組化方案，允許我們在初始化 vuex 的時候配置 modules。每一個 module 裡面又分別包含 state 、action 等，看似是多個狀態樹，其實還是基於 rootState 的子樹。細分後整個 state 結構就清晰了，管理起來也方便許多。
由於 vuex 的靈活性，帶來了編碼不統一的情況，完整的閉環是 store.dispatch('action') -> action -> commit -> mutation -> getter -> computed，實際上中間的環節有的可以省略，因為 API 文件提供了以下幾個方法 mapState、mapGetters、mapActions、mapMutations，然後在元件裡可以直接調取任何一步，還是專案小想怎麼呼叫都可以，專案大的時候，就要考慮 vuex 使用的統一性，我的建議是不論多簡單的流程都跑完整個閉環，形成程式碼的統一，方便後期管理，在我的元件裡只允許出現 dispatch 和 mapGetters，其餘的流程都在名為 store 的 vuex 資料夾裡進行。
基於上面一條，說下每個過程裡面要做什麼，前後端資料一定會有不一致的地方，或是資料結構，或是欄位命名，那麼究竟應該在哪一步處理資料轉換的邏輯呢？有人會說其實哪一步都可以實現，其實不然，我的建議如下
在發 dispatch 之前就處理好元件內需要傳的引數的資料結構和欄位名
到了 action 允許我們做的事情很多，因為這部支援非同步，支援 state, rootState, commit, dispatch, getters，由此可見責任重大，首先如果後端需要部分其他 module 裡面的資料，要通過 rootState 取值再整合到原有資料上，下一步發出請求,建議（async await + axios），拿到資料後進行篩選轉換，再傳送 commit 到 mutation
這一步是將轉換後的資料更新到 state 裡，可能會有資料分發的過程（傳進一個 object 改變多個 state 中 key 的 value），可以轉換資料結構，但是儘量不做欄位轉換，在上一步做
此時的 store 已經更新，使用 getter 方法來取值，token: state => state.token，單單的取值，儘量不要做資料轉換，需要轉換的點在於多個地方用相同的欄位，但是結構不同的情況（很少出現）。
在元件裡用 mapGetters 拿到對應的 getter 值。
四、 打包優化
上面說了程式碼方面的規範和優化，下面說下重點的打包優化，前段時間打包的 vender bundle 足足 1.4M，app bundle 也有 270K，app bundle 可以通過元件懶載入解決，vender 包該怎麼解決？
有人會質疑是不是沒壓縮或依賴包沒去重，其實都做了就是看到的 1.4M。
解決方法很簡單，打包 vender 時不打包 vue、vuex、vue-router、axios 等，換用國內的 bootcdn 直接引入到根目錄的 index.html 中。
例如：
在 webpack 裡有個 externals，可以忽略不需要打包的庫
externals: {
'vue': 'Vue',
'vue-router': 'VueRouter',
'vuex': 'Vuex',
'axios': 'axios'
}
複製程式碼此時的 vender 包會非常小，如果不夠小還可以拆分其他的庫，此時增加了請求的數量，但是遠比載入一個 1.4M 的 bundle 快的多。
補充： 檢視打包檔案檢視：
# build for production and view the bundle analyzer report
npm run build --report
複製程式碼總結
本文談的優化可以解決部分效能問題，實際開發細節很多，總之按著規範寫程式碼，團隊的編碼風格儘量統一，處理細節上多加思考，大部分效能問題都能迎刃而解。
文章出自 orange 的 個人部落格 orangexc.xyz/