公司內部技術分享之Vue.js和前端工程化

時間 2019-11-13

標籤公司內部技術分享 vue.js vue 前端工程欄目 JavaScript 简体版

原文原文鏈接

今天主要的核心話題是Vue.js和前端工程化。我將結合我這兩年多的工做學習經從來談談這個，主要側重點是前端工程化，Vue.js側重點相對前端工程化，比重不是特別大。css

Vue.js

Vue.js和React.js、Angular.js並駕齊驅號稱前端三大框架(前端最經常使用的這三大框架，大中小公司均採用)。
Vue.js是一個叫尤雨溪及其餘的團隊開發的，不過早年是他本身獨立作出來的。這一點我以爲他很牛逼。
我以爲每一個作開發的朋友們，都要有一個本身的開源項目，本身的開源項目能夠是本身工做三到四年發現有不少地方是重複的，能夠寫一個框架減小沒必要要的重複工做量，如今已經有不少人正在作，好比renren-security、jeesite等開源項目，經過它們很容易就能夠寫出一個功能齊全的後臺管理系統。也能夠是本身開發中經常使用的某些組件，那些組件每次開發都要用，能夠將其收集起來，針對其中某個api進行改造，好比Hutools這個開源項目在這個方面就作的挺不錯。又或者是在校的學生們，本身能夠不斷實踐，寫寫圖書管理系統或者是根據學校某些需求定製一個系統出來，而後將其開源，我以爲這樣一來，對於之後畢業出來找工做也是頗有幫助的。總而言之，開源項目能夠是不少，它能夠是一個電商系統、CMS、CRM或ERP之類的，也能夠是讀書筆記、書籍收集、文章收集等。html

關於Vue.js這部分，主要參考Vue.js的官方網站和一些開源項目前端

下面正式開講vue

工具

Devtools

Devtools其目的主要是用於瀏覽器調試Vue相關的項目(由於Vue.js中的標籤並不只僅是html相關的，還有如el這類的標籤及其相關的dom關係等，這些都是常規的瀏覽器調試所不能作到的)java

vue-devtools開源項目地址
 圖文詳解vue.js devtools使用方法
使用Devtools調試對應的Vue.js應用程序，效果如圖:node

Vue CLI

1.Vue CLI具備以下優勢
(1)功能豐富
對 Babel、TypeScript、ESLint、PostCSS、PWA、單元測試和 End-to-end 測試提供開箱即用的支持。webpack

(2)易於擴展
它的插件系統可讓社區根據常見需求構建和共享可複用的解決方案。git

(3)無需 Eject
Vue CLI 徹底是可配置的，無需 eject。這樣你的項目就能夠長期保持更新了。github

(4)CLI 之上的圖形化界面
經過配套的圖形化界面建立、開發和管理你的項目。web

(5)即刻建立原型
用單個 Vue 文件即刻實踐新的靈感。

(6)面向將來
爲現代瀏覽器輕鬆產出原生的 ES2015 代碼，或將你的 Vue 組件構建爲原生的 Web Components 組件。

2.Vue CLI的三種構建方式
第一種方式(常規)

npm install -g @vue/cli
vue create hello-world
npm run server

第二種方式(舊版本2.x)

npm install -g @vue/cli-init
vue init webpack my-project

第三種方式(GUI)
在git bash中輸入以下命令，便可建立vue腳手架項目:

vue ui

效果圖以下:

Vue Loader

Vue Loader的做用是解析和轉換 .vue 文件，提取出其中的邏輯代碼 script、樣式代碼 style、以及 HTML 模版 template，再分別把它們交給對應的 Loader 去處理。

Vue Loader官方指南
Vue Loader的例子不少，如圖所示:

從圖中咱們就能夠看出它們的職責和做用，正好驗證前面說的script（邏輯代碼)、style(樣式代碼)、template(html模板)。
換句話說，Vue Loader你能夠理解爲一個tomcat服務器，它不只僅能解析jsp和servlet，還能處理css、html、js等前端三劍客。

核心插件

Vue Router

Vue Router文檔
Vue Router 是 Vue.js 官方的路由管理器。它和 Vue.js 的核心深度集成，讓構建單頁面應用變得易如反掌。
包含的功能以下:
(1)嵌套的路由/視圖表
(2)模塊化的、基於組件的路由配置
(3)路由參數、查詢、通配符
(4)基於 Vue.js 過渡系統的視圖過渡效果
(5)細粒度的導航控制
(6)帶有自動激活的 CSS class 的連接
(7)HTML5 歷史模式或 hash 模式，在 IE9 中自動降級
(8)自定義的滾動條行爲

Vuex

Vuex 是一個專爲 Vue.js 應用程序開發的狀態管理模式。它採用集中式存儲管理應用的全部組件的狀態，並以相應的規則保證狀態以一種可預測的方式發生變化。Vuex 也集成到 Vue 的官方調試工具 devtools extension，提供了諸如零配置的 time-travel 調試、狀態快照導入導出等高級調試功能。

Vuex官方文檔

Vue服務端渲染

Vue.js 是構建客戶端應用程序的框架。默認狀況下，能夠在瀏覽器中輸出 Vue 組件，進行生成 DOM 和操做 DOM。然而，也能夠將同一個組件渲染爲服務器端的 HTML 字符串，將它們直接發送到瀏覽器，最後將這些靜態標記」激活」爲客戶端上徹底可交互的應用程序。服務器渲染的 Vue.js 應用程序也能夠被認爲是」同構」或」通用」，由於應用程序的大部分代碼均可以在服務器和客戶端上運行。

Vue.js服務端渲染指南

這個服務端渲染一般能夠用node.js中的express框架，固然了，也能夠用koa或者egg.js等。

資源列表

Vue.js官方倉庫
 Vue.js優選
 Vue.js資源

關於Vue.js學習方式，我的建議對HTML+CSS+JavaScript要掌握的比較好才行，不只僅對前端而言，後端也亦如此。
爲何這麼說呢？
一般來講作Java後臺開發的，基本上前端也會。
另外從一位前端工程師的角度來看，前端的技術與後端相比，更新迭代更快，可是不變的仍是前端三劍客那點東西。把握了這些基本上學任何前端框架都是一件很容易的事情。
正如Vue.js起步中所說的那樣:
官方指南假設你已瞭解關於 HTML、CSS 和 JavaScript 的中級知識。若是你剛開始學習前端開發，將框架做爲你的第一步可能不是最好的主意——掌握好基礎知識再來吧！以前有其它框架的使用經驗會有幫助，但這不是必需的。
另外我一直認爲，公司研發崗位，如開發人員、測試人員、運維人員、運營人員、產品人員等，至少要知道彼此在作什麼以及彼此工做之間聯繫，我以爲這樣會比較好，否則很容易會陷入一個死循環，你能夠理解爲」閉關鎖國」。

本次的Vue.js內部分享不算太多，只不過是全局概況一下，更多的內容，能夠去官方網站上學習。

我以爲做爲一名研發人員，必定要養成經過官網學習的習慣，像博客之類的能夠做爲一個輔助或者深刻的學習方式。經過官方網站學習，我以爲整體可讓你造成一個全局的認識，這種認識，可讓你舉一反三或觸類旁通。

舉個例子說一下，最近由於某個電商項目二次開發，而該二次開發用的是ThinkPHP框架，雖然我沒有接觸過PHP方面的，可是我經過官網相關知識，一下就瞭解了它的大體，ThinkPHP是基於MVC的，而正好能夠聯繫到Java中的SSM,其也是基於MVC。

前端工程化

這一部份內容我將結合個人開發經歷和《前端工程化體系設計與實踐》這本書。

先後端分離

原始的先後端分離方式

前端把頁面模板寫好，後臺將頁面模板改成jsp或者freemaker、volocity等動態模板語言。

曾經作的一個智能酒店項目就是使用這種方式。這樣作最很差的地方是，若是公司是先後端職責分明的話，前端每改動某個頁面時，都須要將修改的後發給後臺人員，後臺人員將其改成jsp。這樣一來效率及其低下，固然了，小公司是不會這麼作的，小公司都是後臺兼任前端的，天然就能夠省去這些沒必要要的時間成本。

原始的先後端分離方式優缺點(以模板語言採用jsp爲例):

優勢:
(1)嚴格按照MVC模式，職責分明，效率仍是挺高的，舉個例子說明，視圖(jsp)只負責展現數據而不作過多的邏輯判斷處理，過多的邏輯判斷應該交給控制器內部的業務邏輯方法進行處理。
(2)因爲一般採用的是模板語言(jsp、freemaker、volocity等)，視圖裏能夠作必定的邏輯判斷和處理，所以沒必要嵌入大量的js，大量的js若是某一個有問題，將會致使整個有問題，好比寫一個ajax方法，可是參數沒有傳進去，這時頁面上將不會顯示數據，只會空白，只能用瀏覽器調試才能發現是哪裏有問題，若是是jsp的話，直接就會報500錯誤(或者內部作一些處理，讓其跳轉到錯誤指定界面);
(3)減小HTTP請求(只需請求一次便可,若是頁面是html的話，須要大量的js函數請求後端路由，在必定程度上會增大服務器的壓力，致使頁面延遲);
(4)不用考慮瀏覽器兼容性(有些js的方式因爲瀏覽器的兼容性而不能正常調用或者須要進行改動);

缺點:
(1)複用性較差(因爲返回的不是json數據而是視圖，致使複用性不是特別好);
(2)過於依賴Java運行環境(須要servlet容器);
(3)先後端未分離，耦合性高，可讀性差(jsp中嵌入java代碼及其大量的jstl標籤，致使可讀性很差，耦合性也高，固然了，若是作一個良好的設計並遵循的話，耦合性是能夠下降的，可讀性也是能夠提升的);

總的來講，用jsp做爲視圖展現，可複用性不是特別好，因而曾經的第二個項目LMS(智能門鎖系統)，視圖就變成了HTML，由Ajax做爲先後端交互的支點。

用Ajax的優缺點以下:

優勢:
(1)開發過程先後端脫離，經過接口進行JSON數據傳輸(職責分明更加明確);
(2)跨平臺能力更強，依託於瀏覽器的支持(基本上人們經常使用的瀏覽器(谷歌、火狐、IE、360等)都支持)
(3)可複用性更好;

缺點:
(1)開發難度大，考慮瀏覽器兼容性;
(2)頁面請求過多(參考網站十大優化原則，其中一點優化原則是減小HTTP請求，過多的HTTP請求對於性能是十分消耗的);
(3)接口代碼須要新增不少(這一點我相信許多開發人員都有這樣的感觸);
(4)大量的邏輯判斷都須要使用js(前面我說過,js是不容許一丁點錯誤的，一旦錯誤，體驗很很差，至少jsp報錯500，可讓其跳轉到一個友好的提示，而html就不行了，直接就沒有數據或者是若是牽扯到佈局，直接會影響到用戶體驗);

總的來講，開發中通常二者兼用。

不事後來，Vue.js、Angular.js、React.js火起來了，先後端分離實踐更佳的方式到來。

由於即使徹底採用jsp做爲視圖展現/採用HTML做爲視圖展現或者二者兼用，仍是存在很多的問題的。這一點後面會講到的。

前端工程化

前端工程化的目的在於提升生產效率

前端工程化的衡量準則

三大衡量準則:

(1)從開發的角度衡量工程化，主要體現爲」快」;
天下武功，惟「快」不破。作項目也是如此，特別是作產品原型，必定要快，快速作出來，而後使用mock套一些假數據，等待產品經理確認是其想要的，而後就能夠開發的。從中也體現着「敏捷」。

(2)從測試的角度衡量工程化，主要體現爲」快」和」準」;

「快」的主要體如今前端工程師和後端工程師並行完成以後的集成測試階段。
「準」的主要體如今集成測試階段對問題的準肯定位。

什麼是集成測試?
集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將全部模塊按照設計要求（如根據結構圖）組裝成爲子系統或系統，進行集成測試。

你能夠將其理解爲一輛車，車在沒有組裝成是一堆大大小小的零件，這些零件通過生產工人生產，組裝工人組裝，質量工人測試。零零散散的零件單個測試也許是沒有問題的，可是組裝成一輛車的時候，這個時候就可能會出現問題。

(3)從部署角度衡量工程化，主要體現爲」穩」;
一般會使用持續集成工具(如Jenkins、 Travis CI等)，一般會將每一次開發人員的代碼提交進行編譯、測試、發佈，若是編譯或測試有問題，直接就會將本次構建取消，回滾到穩定版本。這樣一來，能夠確保」穩」。

前端工程化的進化歷程

前端工程化的3個階段

(1)本地工具鏈-工程化不等同於工具化;
工程化的核心並不是工具。前端工程化是以規範工做流程爲手段，以工具爲實現媒介，其最終目的是爲了提升研發效率以及保證Web產品的線上質量。
若是要給前端工程化一個明肯定義的話，比較恰當的定義以下:

前端工程化是一系列工具和規範的組合，規範爲藍本，工具爲實現。其中規範以下:
a.項目文件的組織結構，好比使用目錄名稱區分源文件和目標文件;
b.源代碼的開發範式，好比使用既定的模塊化方案;
c.工具的使用規範，好比工程化自身的配置規範;
d.各階段環境的依賴，好比部署功能的實現須要目標服務器提供SSH全新;

另外工具鏈的統一，另外一個好處是鞏固了流程的規範性，開發者使用統一的工具鏈、遵循統一的規範進行業務代碼的編寫，利於多人協做和程序維護。

試想一下:
假設你身處一個團隊，團隊中沒有任何的開發規範，遇到一些需求，每每這些需求是能夠經過引入某一個框架來實現的，但因爲沒有任何的限制，原本一個框架能夠實現多個需求，但像前面提到的沒有任何規範限制，就變成了多個框架實現多個需求。這樣一來項目將會愈來愈亂，不利於團隊協做。我曾經就作過這樣的項目，深有感觸。

(2)管理平臺-進一步淡化差別、加深規範;

管理平臺形態的工程化需達到以下幾點:
a.淡化環境差別性，保證構建產出一致性;
b.權限集中管理，提升安全性;
c.項目版本集中管理，便於危機處理，好比版本回滾等;

管理平臺形態將各個功能模塊的執行環境集中化，從各模塊實現角度來說與本地工具鏈基本一致。

(3)持續集成-前端工程化的目標是融入總體
即便進化達到管理平臺形態，前端工程化方案所能解決問題的本質仍然只是將前端工程師與後端工程師的工做解耦。雖然提升了兩端的工做效率，可是各自的工做流倒是孤立的。前端有了構建和部署，後端也有了相應的階段，兩方的工做流是分離的，最終的融合工做仍然難以免繁瑣的人工操做。

舉個例子，好比後端修改了某個接口，前端某個dom與這個接口關係緊密，接口變化了，dom渲染也要隨之變化，可是因爲工做流是分開的，前端工程師並不知道這一點。咱們常常強調一點，要增強溝通，可是當項目緊急期到來時，每一個人手裏任務一大堆，這時溝通就可能會少了不少，這時像上面說的，接口發生變化時，前端工程師並不知情，直到由於某些操做發生問題時，才知道原來是接口變了。另外從某個角度來看，接口的設計原則應該是與前端相隔離的，可是實際中並不是如此。