Vue入門學習筆記

阿新 • • 發佈：2020-10-05

Vue 的核心庫只關注檢視層，方便與第三方庫或既有專案整合。

HTML + CSS + JS : 檢視： 給使用者看，重新整理後臺給的資料

網路通訊： axios

頁面跳轉： vue-router

狀態管理：vuex

Vue-UI : ICE、 Element UI

一、VUE 概述

Vue (讀音/vju/, 類似於view)是一套用於構建使用者介面的漸進式框架，釋出於2014年2月。

與其它大型框架不同的是，Vue被設計為可以自底向上逐層應用。

Vue的核心庫只關注檢視層，不僅易於上手，還便於與第三方庫(如: vue-router: 跳轉，vue-resource: 通訊，vuex:管理)或既有專案整合。

二、前端核心知識分析

1. 前端三要素

HTML(結構層) : 超文字標記語言(Hyper Text Markup Language) ，決定網頁的結構和內容
CSS(表現層) : 層疊樣式表(Cascading Style sheets) ，設定網頁的表現樣式
JavaScript(行為層) : 是一種弱型別指令碼語言，其原始碼不需經過編譯，而是由瀏覽器解釋執行,用於控制網頁的行為

1.1 CSS 前處理器有

SASS：基於Ruby，通過服務端處理，功能強大。解析效率稿。需要學習 Ruby 語言，上手難度高於LESS。
LESS：基於 NodeJS，通過客戶端處理，使用簡單。功能比 SASS 簡單，解析效率也低於 SASS，但在實際開發中足夠了，所以後臺人員如果需要的話，建議使用 LESS。

1.2 Native原生JS開發

原生JS開發，也就是讓我們按照【ECMAScript】標準的開發方式，簡稱是ES,特點是所有瀏覽器都支援。截止到當前部落格釋出時間，ES標準已釋出如下版本:

ES3
ES4 (內部,未正式釋出)
ES5 (全瀏覽器支援)
ES6 (常用，當前主流版本: webpack打包成為ES5支援! )
ES7
ES8
ES9 (草案階段)

區別就是逐步增加新特性。

1.3 TypeScript微軟的標準

TypeScript是一種由微軟開發的自由和開源的程式語言。它是JavaScript的一個超集，而且本質上向這個語言添加了可選的靜態型別和基於類的面向物件程式設計。由安德斯海爾斯伯格（C#、Delphi、TypeScript 之父； .NET 創立者）主導。

該語言的特點就是除了具備 ES 的特性之外還納入了許多不在標準範圍內的新特性，所以會導致很多瀏覽器不能直接支援 TypeScript 語法，需要編譯後（編譯成 JS ）才能被瀏覽器正確執行。

2. JavaScript框架

前端三大框架：Angular、React、Vue

jQuery: 大家熟知的JavaScript框架，優點是簡化了DOM操作，缺點是DOM操作太頻繁,影響前端效能;在前端眼裡使用它僅僅是為了相容IE6、7、8。
Angular: Google收購的前端框架，由一群Java程式設計師開發，其特點是將後臺的MVC模式搬到了前端並增加了模組化開發的理念，與微軟合作，採用TypeScript語法開發;對後臺程式設計師友好，對前端程式設計師不太友好;最大的缺點是版本迭代不合理(如: 1代-> 2代，除了名字，基本就是兩個東西;截止發表部落格時已推出了Angular6)。
React: Facebook出品，一款高效能的JS前端框架;特點是提出了新概念[虛擬DOM]用於減少真實DOM操作，在記憶體中模擬DOM操作，有效的提升了前端渲染效率;缺點是使用複雜，因為需要額外學習一門[JSX] 語言。
Vue:一款漸進式JavaScript框架，所謂漸進式就是逐步實現新特性的意思，如實現模組化開發、路由、狀態管理等新特性。其特點是綜合了Angular (模組化)和React (虛擬DOM)的優點;。
Axios :前端通訊框架；因為Vue 的邊界很明確，就是為了處理DOM，所以並不具備通訊能力，此時就需要額外使用一個通訊框架與伺服器互動；當然也可以直接選擇使用jQuery提供的AJAX通訊功能。

3. UI框架

Ant-Design:阿里巴巴出品，基於React的UI框架
ElementUI、 iview、 ice: 餓了麼出品，基於Vue的UI框架
Bootstrap: Twitter推出的一個用於前端開發
AmazeUI:又叫"妹子UI"，一款HTML5跨屏前端框架

4. JavaScript構建工具

Babel: JS編譯工具，主要用於瀏覽器不支援的ES新特性，比如用於編譯TypeScript
WebPack: 模組打包器，主要作用是打包、壓縮、合併及按序載入

前端開發主要使用WebPack。

5. 三端合一

5.1 混合開發（Hybid App）

主要目的是實現一套程式碼三端統一(PC、Android:.apk、iOS:.ipa )並能備夠呼叫到底層件(如:感測器、GPS、攝像頭等)，打包方式主要有以下兩種:

雲打包: HBuild -> HBuildX， DCloud出品; API Cloud
本地打包: Cordova (前身是PhoneGap)

5.2 微信小程式

詳見微信小程式官網，這裡就只介紹一個方便小程式開發的框架：

WeUI

6. 後端技術

前端人員為了方便開發也需要掌握一定的後端技術，但我們Java後臺人員知道後臺知識體系極其龐大複雜，所以為了方便前端人員開發後臺應用，就出現了NodeJS這樣的技術。

NodeJS的作者已經聲稱放棄NodeJS (說是架構做的不好再加上笨重的node_ modules，可能讓作者不爽了吧)，開始開發全新架構的Deno

既然是後臺技術，那肯定也需要框架和專案管理工具，NodeJS 框架及專案管理工具如下:

Express: NodeJS框架
Koa: Express簡化版
NPM: 專案綜合管理工具，類似於Maven
YARN: NPM的替代方案，類似於Maven和Gradle的關係

7. 主流前端框架

Vue.js

7.1 iView

iview 是一個強大的基於 Vue 的 UI 庫，有很多實用的基礎元件比 elementui 的元件更豐富，主要服務於 PC 介面的中後臺產品。使用單檔案的 Vue 元件化開發模式基於 npm + webpack + babel 開發，支援 ES2015 高質量、功能豐富友好的 API，自由靈活地使用空間。

備註：屬於前端主流框架，選型時可以考慮使用，主要特點是移動端支援較多

7.2 ElementUI

Element 是餓了麼前端開源維護的 Vue UI 元件庫，元件齊全，基本涵蓋後臺所需的所有元件，文件講解詳細，例子也很豐富。主要用於開發 PC 端的頁面，是一個質量比較高的 Vue UI 元件庫。

官網地址
Github：vue-element-admin

備註：屬於前端主流框架，選型時可以考慮使用，主要特點是桌面端支援較多

7.3 ICE

飛冰是阿里巴巴團隊基於 React/Angular/Vue 的中後臺應用解決方案，在阿里巴巴內部，已經有270多個來自幾乎所有 BU 的專案在使用。飛冰包含了一條從設計端到開發端的完整鏈路，幫助使用者快速搭建屬於自己的中後臺應用。

備註:主要元件還是以 React 為主，截止 2019 年 02 月 17 日更新部落格前對 Vue 的支援還不太完善，目前尚處於觀望階段

7.4 VantUI

Vant UI 是有贊前端團隊基於有贊統一的規範實現的 Vue 元件庫,提供了一整套 UI 基礎元件和業務元件。通過 Vant，可以快速搭建出風格統一的頁面，提升開發效率。

7.5 AtUI

at-ui是一款基於 Vue 2.x 的前端UI元件庫,主要用於快速開發PC網站產品。它提供了一套 npm + webpack + babel 前端開發工作流程，CSS 樣式獨立，即使採用不同的框架實現都能保持統一的UI風格。

7.6 CubeUI

cube-ui 是滴滴團隊開發的基於 Vue.js 實現的精緻移動端元件庫。支援按需引入和後編譯，輕量靈活；擴充套件性強，可以方便地基於現有元件實現二次開發。

混合開發

Flutter

Flutter是谷歌的移動端UI框架，可在極短的時間內構建Android 和iOs.上高質量的原生級應用。Flutter 可與現有程式碼一起工作,它被世界各地的開發者和組織使用,並且Flutter是免費和開源的。

備註: Google出品，主要特點是快速構建原生APP應用程式，如做混合應用該框架為必選框架

lonic

lonic 既是一個 CSS 框架也是一個 Javascript UI 庫，lonic 是目前最有潛力的一款 HTML5 手機應用開發框架。通過 SASS 構建應用程式，它提供了很多 UI 元件來幫助開發者開發強大的應用。它使用 JavaScript MVVM框架和 AngularJS/Vue 來增強應用。提供資料的雙向繫結，使用它成為 Web 和移動開發者的共同選擇。

微信小程式

mpvue

mpvue 是美團開發的一一個使用 Vue.js 開發小程式的前端框架，目前支援微信小程式、百度智慧小程式，頭條小程式和支付寶小程式。框架基於 Vue.js ，修改了的執行時框架 runt ime 和程式碼編譯器 compiler 實現，使其可執行在小程式環境中，從而為小程式開發引入了 Vue.js 開發體驗。

備註:完備的Vue開發體驗，並且支援多平臺的小程式開發，推薦使用

WeUl

WeUI 是一套同微信原生視覺體驗一致的基礎樣式庫，由微信官方設計團隊為微信內網頁和微信小程式量身設計，令使用者的使用感知更加統一。包含 button、cell、 dialog、toast、article、 icon 等各式元素。

三、瞭解前後端分離的演變史

3.1 後端為主的 MVC 時代

為了降低開發的複雜度，以後端為出發點,比如：Struts、 SpringMVC 等框架的使用，就是後端的MVC時代；

以 Spring MVC 的流程為例：

發起請求到前端控制器( DispatcherServlet )
前端控制器請求 HandlerMapping 查詢 Handler, 可以根據 xml 配置、註解進行查詢
處理器對映器 HandlerMapping 向前端控制器返回 Handler
前端控制器呼叫處理器介面卡去執行Handler
處理器介面卡去執行 Handler
Handler 執行完成給介面卡返回 ModelAndView
處理器介面卡向前端控制器返回 ModelAndView ，Mode lAndView 是 SpringMVC 框架的一一個底層物件，包括 Model 和 View
前端控制器請求檢視解析器去進行檢視解析，根據邏輯檢視名解析成真正的檢視( JSP )
檢視解析器向前端控制器返回 View
前端控制器進行檢視渲染，檢視渲染將模型資料（在 ModelAndView 物件中）填充到 request 域
前端控制器向用戶響應結果

優點

MVC是一個非常好的協作模式，能夠有效降低程式碼的耦合度,從架構上能夠讓開發者明白程式碼應該寫在哪裡。
為了讓View更純粹,還可以使用Thymeleaf、Freemarker 等模板引擎，使模板裡無法寫入Java程式碼,讓前後端分工更加清晰。

缺點

前端開發重度依賴開發環境，開發效率低，這種架構下，前後端協作有兩種模式：
- 第一種是前端寫 DEMO，寫好後，讓後端去套模板。好處是 DEMO 可以本地開發，很高效。不足是還需要後端套模板，有可能套錯，套完後還需要前端確定，來回溝通調整的成本比較大；
- 另一種協作模式是前端負責瀏覽器端的所有開發和伺服器端的 View 層模板開發。好處是 UI 相關的程式碼都是前端去寫就好，後端不用太關注，不足就是前端開發重度繫結後端環境，環境成為影響前端開發效率的重要因素。
前後端職責糾纏不清：模板弓|擎功能強大，依舊可以通過拿到的上下文變數來實現各種業務邏輯。這樣，只要前端弱勢一點，往往就會被後端要求在模板層寫出不少業務程式碼。還有一個很大的灰色地帶是 Controller ，頁面路由等功能本應該是前端最關注的，但卻是由後端來實現。Controller 本身與 Model 往往也會糾纏不清，看了讓人咬牙的業務程式碼經常會出現在 Controller 層。這些問題不能全歸結於程式設計師的素養，否則 JSP 就夠了。
對前端發揮的侷限性：效能優化如果只在前端做空間非常有限，於是我們經常需要後端合作，但由於後端框架限制，我們很難使用【Comet】 、【BigPipe】 等技術方案來優化效能。

注：在這期間（2005 年以前），包括早期的 JSP、PHP 可以稱之為 Web 1.0 時代。因為時代在變、技術在變、什麼都在變。

世界著名作家、大思想家斯賓塞·約翰遜的一句話：唯一不變的是變化本身。

一些陳舊的技術對於市場來說早就過時了，比如 JSP。

3.2 基於 AJAX 帶來的 SPA 時代

時間回到 2005 年 AJAX （Asynchronous JavaScript And XM，非同步JavaScript和XML,老技術新用法）被正式提出並開始使用 CDN 作為靜態資源儲存，於是出現了JavaScript王者歸來（在這之前 JS 都是用來在網頁上貼狗皮膏藥廣告的）的 SPA （Single Page Application）單頁面應用時代。

優點

這種模式下，前後端的分工非常清晰，前後端的關鍵協作點是AJAX介面。看起來是如此美妙,但回過頭來看看的話，這與 JSP 時代區別不大。複雜度從服務端的 JSP 裡移到了瀏覽器的 JavaScript，瀏覽器端變得很複雜。類似 Spring MVC，這個時代開始出現瀏覽器端的分層架構：

缺點

前後端介面的約定：如果後端的介面一塌糊塗,如果後端的業務模型不夠穩定,那麼前端開發會很痛苦；不少團隊也有類似嘗試，通過介面規則、介面平臺等方式來做。有了和後端一起沉澱的介面規則，還可以用來模擬資料，使得前後端可以在約定介面後實現高效並行開發。
前端開發的複雜度控制：SPA 應用大多以功能互動型為主，JavaScript 程式碼過十萬行很正常。大量 JS 程式碼的組織，與 View 層的繫結等，都不是容易的事情。

3.3 前端為主的 MV* 時代

此處的 MV* 模式如下：

MVC （同步通訊為主）：Model、View、Controller
MVP （非同步通訊為主）： Model、 View、 Presenter
MVVM （非同步通訊為主）：Model、 View、 ViewModel

為了降低前端開發複雜度，湧現了大量的前端框架，比如：AngularJS、 React、 Vue.js 、EmberJS等，這些框架總的原則是先按型別分層,比如 Templates、Controllers、 Models, 然後再在層內做切分，如下圖：

優點

前後端職責很清晰：前端工作在瀏覽器端，後端工作在伺服器端。清晰的分工，可以讓開發並行，測試資料的模擬不難，前端可以本地開發。後端則可以專注於業務邏輯的處理，輸出 RESTful 等介面。
前端開發的複雜度可控：前端程式碼很重，但合理分層，讓前端程式碼能各司其職。這一塊蠻有意思的，簡單如模板特性的選擇，就有很多講究。並非越強大越好，限制什麼，留下哪些自由，程式碼應該如何組織，所有這一切設計都有很大學位，得花一本書的厚度去說明。
部署相對獨立：可以快速改進產品的體驗。

缺點

程式碼不能複用。比如後端依舊需要對資料做各種校驗，校驗邏輯無法複用瀏覽器端的程式碼。如果可以複用，那麼後端的資料校驗可以相對簡單化。
全非同步，對 SEO 不利。往往還需要服務端做同步渲染的降級方案。
效能並非最佳，特別是移動網際網路環境下。
SPA 不能滿足所有需求，依舊存在大量多頁面應用。URL Design 需要後端配合，前端無法完全掌握。

3.4 NodeJS 代理的全棧時代

前端為主的 MV* 模式解決了很多很多問題，但如上所述，依舊存在不少不足之處。隨著 NodeJS 的興起， JavaScript 開始有能力執行在服務端。這意味著可以有一種新的研發模式：

在這種研發模式下，前後端的職責很清晰。對前端來說，兩個UI層各司其職：

Front-end UI layer 處理瀏覽器層的展現邏輯。通過 CSS 渲染樣式，通過 JavaScript 新增互動功能，HTML 的生成也可以放在這層,具體看應用場景。
Back-end UI layer 處理路由、模板、資料獲取、Cookie 等。通過路由,前端終於可以自主把控URL Design，這樣無論是單頁面應用還是多頁面應用，前端都可以自由調控。後端也終於可以擺脫對展現的強關注，轉而可以專心於業務邏輯層的開發。

通過 Node，Web Server 層也是 JavaScript 程式碼，這意味著部分程式碼可前後複用，需要SEO的場景可以在服務端同步渲染，由於非同步請求太多導致的效能問題也可以通過服務端來緩解。前一種模式的不足，通過這種模式幾乎都能完美解決掉。

與JSP模式相比,全棧模式看起來是一種迴歸，也的確是-種向原始開發模式的迴歸,不過是一種螺旋上升式的迴歸。

基於NodeJS的全棧模式，依舊面臨很多挑戰:

需要前端對服務端程式設計有更進一步的認識。比如 TCP/IP 等網路知識的掌握。
NodeJS 層與 Java 層的高效通訊。NodeJS 模式下，都在伺服器端，RESTful HTTP 通訊未必高效,通過 SOAP 等方式通訊更高效。-切需要在驗證中前行。
對部署、運維層面的熟練了解，需要更多知識點和實操經驗。
大量歷史遺留問題如何過渡。這可能是最大最大的阻力。

注：為什麼說:” 前端想學後臺很難，而我們後端程式設計師學任何東西都很簡單“；就是因為後端程式設計師具備相對完善的知識體系。

3.5 總結

綜上所述，模式也好，技術也罷，沒有好壞優劣之分，只有適合不適合；前後分離的開發思想主要是基於 SoC（關注度分離原則），上面種種模式，都是讓前後端的職責更清晰，分工更合理高效。