首頁 >web前端 >js教程 >實例分享Vue全家桶實作專案總結

實例分享Vue全家桶實作專案總結

小云云原創: 2017-12-28 09:44:502685瀏覽

從前端的角度看，Vue可以說是目前最理想的前端MVVM框架，一切為介面服務，上手難度低，本文將記錄使用Vue全家桶（Vue+Vue-router+Vuex）重構一個jQuery+template專案的過程，以及期間的收穫。本文主要介紹了Vue全家桶實作專案總結(推薦)，小編覺得挺不錯的，現在分享給大家，也給大家做個參考。一起跟著小編過來看看吧，希望能幫助大家。

入門

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程式碼，快速套用到專案中去，使組件部分的前端開發成本接近零。平台需要實作以下幾個功能：

管理元件，支援分類、搜尋、排序
展示元件，支援元件線上預覽/編輯
元件交接，支援產生元件程式碼和基於程式碼重現元件
#使用統計，支援統計元件的使用情況，以便進一步最佳化元件

功能分析

第一版是用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。

實例分享Vue全家桶實作專案總結

相關文章