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

入門

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

Vue

Vue的核心功能是雙向綁定，可以自動實現(xiàn)界面驅(qū)動數(shù)據(jù)變化和數(shù)據(jù)驅(qū)動界面變化，這能極大降低前端富交互應(yīng)用的開發(fā)成本。同類框架不止Vue一個，但Vue的實現(xiàn)借助ES5原生特性，在性能方面有一定優(yōu)勢。

Vue-router

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

Vuex

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

技術(shù)選型

跟jQuery對比

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

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

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

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

適用場景

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

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

項目分析

項目背景

這次重構(gòu)的項目是為上一家公司開發(fā)的前端組件管理系統(tǒng)，選擇重構(gòu)這個項目是因為對需求比較熟悉，這是一個典型的單頁面應(yīng)用，而且復(fù)雜度適中，比較適合用作上手練習(xí)。

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

功能需求

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

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

功能分析

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

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

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

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

當然組件的內(nèi)部文件結(jié)構(gòu)也必須約定下來，如下：

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

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

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

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

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

.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};
}

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

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

以上是項目核心功能。

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

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

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

重構(gòu)

一次重構(gòu)

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

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

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

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

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

二次重構(gòu)

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

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

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

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

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

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

后記

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

本文的完整代碼見Github。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。