Vue全家桶實踐項目總結(推薦)

從前端的角度看，Vue可以說是目前最理想的前端MVVM框架，一切為界面服務，上手難度低，本文就將記錄使用Vue全家桶（Vue+Vue-router+Vuex）重構一個jQuery+template項目的過程，以及期間的收獲。

入門

Vue的官方文檔就是學習Vue的最佳教程，沒有之一，可能因為框架作者是設計出身，沒有后端背景，因此各種抽象概念在Vue里都得以用最容易理解的方式被恰到好處的闡述，這里只簡單介紹Vue、Vue-router、Vuex的概念，要全面學習建議去官方文檔。

Vue

Vue的核心功能是雙向綁定，可以自動實現界面驅動數據變化和數據驅動界面變化，這能極大降低前端富交互應用的開發成本。同類框架不止Vue一個，但Vue的實現借助ES5原生特性，在性能方面有一定優勢。

Vue-router

Vue-router是官方路由，用來組織url和組件間的映射關系，并自動將url的變化響應到組件中去，使開發者只需將關注點放在組件開發上，路由幫你解決相關的瑣碎問題。

Vuex

Vuex提供一種集中式的數據管理模式，用以應對數據流向復雜的情況，比如多個組件共用數據卻各自為營，可能導致該同步的數據沒有同步，或者由于js中Object對象的鉤子在內存里指向同一實例，導致一旦操作原數據就會污染到其他組件，這時就需要一套更有條理的數據操作模式，那就是Vuex。

技術選型

跟jQuery對比

在了解了Vue的基本概念之后，肯定會不自覺的拿他們跟jQuery技術棧做對比，想知道這些東西對我的業務是否真的有必要。

首先MVVM解決的問題能不能用jQuery解決？答案是肯定的，還記得最初做表單提交時用jQuery從一個一個的input里取值嗎？這就是界面驅動數據；如果做過任何異步交互功能的話，應該都有過用jQuery將Ajax數據填充到界面中各個元素里的經驗，這就是數據驅動界面。雖然能做，但有點繁瑣，即便用上表單驗證插件和前端模板引擎，也仍然需要在各個運行節點手動調用驗證方法和渲染方法，做個網站頁面還好，可當需求復雜到一定程度時，這將是很大的負擔。

然后是路由，路由的本質是通過操作url實現界面切換和界面保持，單頁面應用必備，這個其實跟技術棧沒關系，只要產生了路由需求，即使是基于jQuery的項目也不過是再造了一個路由而已，只不過jQuery時代很少做單頁面應用。

Vuex完全是基于雙向綁定延伸出來的東西，相當于在數據和組件之間加了一個經紀人，組件不能直接操作數據，只能像經紀人提交操作需求，由經紀人去實施操作，以此解決人多手雜造成的各種不可預料的問題，并且數據被從應用中挪了出去，專門建立了一個Store，這樣就杜絕了組件之間數據污染的問題。jQuery應該說不太會有這個需求，因為jQuery完全是手動操作數據，根本沒有意料之外的情況。

適用場景

經過跟jQuery的對比之后，Vue的適用場景就很明顯了，從開發角度講交互越復雜的項目越適合，單頁面最適合，內容類網站最不適合，如果網站中個別頁面有需求也可以局部使用，例如購物車頁面。

當然，這一切都要建立在不兼容IE8的前提下，對于這一點我有點疑惑，因為見到有些2C的站點都在使用Vue，這些前端er是怎么把老板忽悠瘸的？

項目分析

項目背景

這次重構的項目是為上一家公司開發的前端組件管理系統，選擇重構這個項目是因為對需求比較熟悉，這是一個典型的單頁面應用，而且復雜度適中，比較適合用作上手練習。

項目背景是外包類建站公司里，設計環節沉淀了大量可復用組件，設計師往往只需要微調組件就拼湊出頁面，交付給前端，理論上這些組件在前端也可以復用，但實際上前端每次都要重新實現整個頁面，浪費很多人力。

功能需求

這個項目的思路是，將所有組件開發出來，統一錄入到一個平臺上管理，設計師可以到平臺上挑選組件，并實時預覽和調整組件，整個過程所見即所得，平臺會將調整結果生成一串代碼，只要將代碼交給前端，就可以用這串代碼在平臺上重現設計師修改后的組件，并能一鍵復制組件的html/css/js代碼，快速應用到項目中去，使組件部分的前端開發成本接近于零。平臺需要實現以下幾個功能：

1. 管理組件，支持分類、搜索、排序
2. 展示組件，支持組件在線預覽/編輯
3. 組件交接，支持生成組件代碼和基于代碼重現組件
4. 使用統計，支持統計組件的使用情況，便于進一步優化組件

功能分析

第一版是用jQuery+template實現的，這個技術棧太靈活了，優點是什么需求都好做，缺點是怎么做都行，不利于理清思路，往往伴隨著邊做邊改。

組件被統一放在一個widgets/文件夾里，被稱作組件庫，因為是純前端項目沒有文件操作能力，因此組件的讀取依賴一個靜態json文件，這個文件充當組件庫的目錄，其中包括組件分類、標簽、名稱、日期等所有信息，數據結構大概是這樣：

[{
 "title": "導航類",
 "list": [{
 "widget": "bread-1",
 "title": "圖標面包屑",
 "tag": "面包屑/圖標",
 "author": "UI",
 "date": "2015-06-04"
 }, 
 ...]
},
...]

組件在組件庫中以欄目/編號二級文件夾的形式存放，同時約定用存放目錄作為組件代號，例如組件bread-1意味著該組件存放地址是widgets/bread/1/文件夾。

當然組件的內部文件結構也必須約定下來，如下：

widgets
  |-bread
    |-1
      |-album.jpg   //縮略圖
      |-config.json  //配置文件
      |-script.js   //腳本模板
      |-style.css   //樣式模板
      `-temp.htm   //界面模板

有了這些約定，程序就可以通過目錄文件得到所有組件的信息，組件的獲取、展示、檢索也就可以實現了。

組件里最關鍵的是config.json文件，這里面包含該組件的可配置項及其默認值，平臺在展示組件時會讀取這個配置文件，根據配置信息生成配置面板，這里面可以定義組件界面、樣式、腳本中的所有變量，配置文件大概長這樣：

{
 "cssConfig": {
 "fontSize": {
  "name": "字號",
  "value": "12px",
  "type": "text"
 },
 ...
 },
 "jsConfig": {
    ...
 },
 "showConfig": {
 "viewWidth": {
  "name": "柵格寬度",
  "value": 12,
  "type": "number"
 },
 ...
 }
}

配置文件里的cssConfig、showConfig、jsConfig三個分支，就是組件中所有可以修改的變量集合，想將這些變量應用到組件上，需要借助前端模板引擎，所以組件的三大件在開發的時候是用模板語法寫的，經過模板引擎的解析，就能得到配置后的實際html/css/js內容，例如樣式模板大概是這樣的：

.widget-bread-1 {
  font-size: ${fontSize.value}; 
  color: ${textColor.value}; 
}
.widget-bread-1 a { 
  color: ${textColor.value};
}
.widget-bread-1 a:hover{
  color:${hoverColor.value};
}
.widget-bread-1 .ion { 
  font-size: ${iconSize.value}; 
  margin: 0 ${iconMargin.value};
}

在得到組件實際代碼后，只要將結果插入頁面中并適時更新就行了，其中HTML和css可以直接替換文本內容，js因為是模塊化引入的，只替換模塊內容不會重載模塊，必須將整個模塊重命名后進行整體替換，因此js模塊的名稱是隨機的。

這里會有一個問題，有的組件需要在頁面里多次使用，那么這個組件的js選擇器就會發生沖突，這個問題的解決正好可以借助js模塊的那個隨機名稱，我們約定在組件開發中id作為保留變量，由平臺自動賦值一個隨機字符串，這個字符串在組件實例內部相同，多次調用則不同，這樣只要將${id}作為組件父節點的id或class，就解決了選擇器沖突問題，同時也可以作為組件的css命名空間，使可能發生的css命名沖突也解決于無形。

以上是項目核心功能。

此外還用localStorage作為存儲方式實現了單機版的數據統計，可以收集當前瀏覽器的組件使用記錄，以及每個使用時的配置情況，這里主要是對本地存儲的操作，但是項目自身的開發也用到了前端模板，加上組件的模板，都會在第一次加載后用localStorage緩存起來，這些內容的緩存策略不同，用戶數據應該是永久存儲，項目模板應該可以手動更新，組件模板需要視情況而定，存儲的內容多了就需要清理，清理的時候一條一條的去刪除就不現實了，全部刪除可能誤傷其他應用的存儲，這里的做法是將localStorage操作封裝，存儲方法會在在key前加上一個特殊前綴，刪除時只要遍歷本地存儲的key并且判斷是否匹配前綴就知道是否是應用內的存儲了，對應的取值方法也要逆向的先給key加上前綴再去取值。

另外localStorage是只支持字符串存取的，為了方便我們存取對象類型，封裝方法還支持自動轉換，但這個轉換還不能是盲目的遇到對象就轉字符，取值的時候匹配到可以轉對象就自動轉了對象，因為有時候用戶可能真的就存了一個對象字符串進去，取出的時候也希望原樣拿回來，要解決這個問題需要做一個小hack，當存儲方法檢測到值為對象時，會轉成字符串然后在前面拼上一個標識字符串，取值方法只有在檢測到這個標識后才會將后面的字符串還原成對象，這種方式雖然可以滿足需求，但不是很保險，因為這個前綴是固定的，理論上總是有可能遇到中獎的，不知道這個問題還有沒有其他的更優解。

項目的主要功能點就是這些。

重構

一次重構

第一次重構只用了Vue，重構過程中首先體會到的是各種便捷，本來要調用模板引擎做的事框架順便就做了，本來要在js里綁定事件現在模板里直接可以綁定，還有其他各種語法糖。

當然，最重要的還是雙向綁定，基于雙向綁定可以讓界面和數據自動的關聯起來，讓人感覺程序具有了一定的自主能動性，但為了讓這種自主性正常運轉，開發者必須事先規劃好每一步路，這相對jQuery來說就會顯得不那么自由。拿搬磚頭舉例，jQuery好比一個特別靈活的起重機，可以舉重若輕，可以花式搬磚；Vue則像一個萬能遙控器，你告訴他你要把磚頭從某地搬到某地，期間發生什么情況要如何處理，按動按鈕就可以自動搬磚了。

兩種方式各有優劣，起重機開的好可以很靈活，路上遇到坑容易躲避，缺點是你要一趟一趟的開它；按鈕可以一次編程自動運行，缺點是你必須事先把路上的坑實地考察好，把別的車全部調度好，所有的情況說清楚，否則就會翻車或撞車，從jQuery轉到Vue一定會感覺到這種束縛感，逼的你必須”謀而后動”，不能先上車再說。

重構期間很大一部分工作就是建立Vue實例，將散布在js各個角落的數據收集到data中去，將操作數據的過程一點一點的集中到methods中去，將數據的篩選過程集中到computed中去，這整個過程可以清晰的回顧每一個實現細節，反思每一個實現方式是不是合理，其實也就是將原來開起重機的過程歸納成一個一個的遙控器按鈕，當全部歸納完成后，Vue示例也就變成了最終我們的項目，能夠自動運行。

經過重構，依托Vue的各種功能使邏輯部分的代碼量減少了，除此之外對項目本身來說并沒有什么改進，因為沒有路由所以刷新頁面狀態丟失問題仍然存在；因為沒有使用Vuex還遇到一個數據污染的坑，只能用深拷貝解決；并且基于組件的開發模式，讓代碼組織更零碎了，這些問題都需要二次重構。

二次重構

二次重構目標是完善路由、Vuex、代碼組織、野狗云后端。

雖然有了第一次重構的經驗，但二次重構一開始還是有點茫然，路由和Vuex應該先上哪一個？想了想，路由做的事是”拆”，Vuex做的事是”改”，感覺改完再拆的工作量會小一點，所以先上Vuex。

Vuex的概念憑空理解有點抽象，一旦用上卻覺得的得心應手，而且這個東西不像路由，幾乎不需要區分場景都可以用，引入Vuex后數據污染的問題自然就解決了，而且Vuex帶來的 action => mutation => store 流程一旦接受了真的會讓事情變簡單，引入Vuex的過程基本就是將data轉移到store，將數據操作分散到actions,getters,mutations中去，同時很多同步數據操作都不需要了，從而使代碼量又減少了一些。

之后開始引入路由，一開始拿不準應該怎么劃分視圖，大的視圖肯定是登錄、注冊、主界面，問題是主界面需不需要再細分，理論上可以分的很細，但結合應用實際使用場景發現，界面的切換相對頻繁，組件頻繁載入和卸載的開銷會很大，而且將耦合緊密的組件拆到不同的視圖，需要記錄很多狀態信息，有點得不償失，最終作罷，沒有將主視圖繼續分下去。考慮到三個視圖的訪問重疊性不高，自然就需要將組件做成異步加載，只在訪問到的時候才加載組件，Vue自身支持異步組件，所以這件事變得非常簡單，只要能返回一個Promise，你可以使用任意方式獲取組件。

接下來要接入野狗云，實現真正的用戶管理和數據統計，野狗云可以提供用戶鑒權和數據存儲等一系列功能，通過它只需要用js就可以開發一個完整的WEB應用。這樣之前所有對localStorage的操作都要改成對野狗云的操作，數據到了云端也變得更可靠了。

至此二次重構就完成了，業務代碼總體感覺減少了很多，但總代碼量估計沒少多少，畢竟還增加了三個框架文件，不過經過重重拆分，文件數量從當初的三兩個js變成了十來個js，模塊化方面用的seajs而不是webpack，因為個人對 webpack仍然持觀望態度，目前還感覺不到用它的必要性，關鍵是基于webpack開發的代碼會夾雜很多私貨，讓你的代碼變得不原生，離了他就運行不起來，這個我不太能接受，而且在多頁面場景seajs配合本地緩存比webpack更有優勢，當然了，他們的的區別就跟jQuery和Vue的區別一樣，本質不是一個東西，關鍵在于使用場景，適合的就是最好的。

后記

經過兩次重構的實踐和踩坑，對Vue框架有了更深刻的認識，Vue想要用的靈活自如，對開發者的項目架構能力有一個最低要求，如果要將Vue引入底層，對基礎設施建設者的規劃能力也有一個最低要求，這些都是jQuery技術棧所不存在的，使用Vue的過程也是接受這些約束的過程，他們能引導開發者建立自己的規則體系，這是好事也是大勢所趨，畢竟真正的自由只存在于規則中。

本文的完整代碼見Github。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持億速云。