談一談對(duì)vue組件化的理解？

聽到“理解”兩個(gè)字我們就要注意了，看似一道開放性的問題，實(shí)際是要考察我們對(duì)VUE組件化的認(rèn)知基礎(chǔ)。

我們可以從定義、優(yōu)點(diǎn)、使用場(chǎng)景和注意事項(xiàng)等方面展開陳述，同時(shí)要強(qiáng)調(diào)vue中組件化的一些特點(diǎn)。

始終不變的是“從源碼深入解決問題，最終達(dá)到深入淺出的效果?！?/p>

源碼分析1：組件定義

src\core\global-api\assets.js

（?文件中的位置）

vue-loader會(huì)編譯template為render函數(shù)，最終導(dǎo)出的依然是組件配置對(duì)象。?

源碼分析2：組件化優(yōu)點(diǎn)

lifecycle.js - mountComponent()

?組件、Watcher、渲染函數(shù)和更新函數(shù)之間的關(guān)系

源碼分析3：組件化實(shí)現(xiàn)

構(gòu)造函數(shù)，

src\core\global-api\extend.js

實(shí)例化及掛載，

src\core\vdom\patch.js - createElm()

正確解答：

1、組件是獨(dú)立和可復(fù)用的代碼組織單元。組件系統(tǒng)是 Vue 核心特性之一，它使開發(fā)者使用小型、獨(dú)立和通常可復(fù)用的組件構(gòu)建大型應(yīng)用；

2、組件化開發(fā)能大幅提高應(yīng)用開發(fā)效率、測(cè)試性、復(fù)用性等；

3、組件使用按分類有：頁面組件、業(yè)務(wù)組件、通用組件；

4、vue的組件是基于配置的，我們通常編寫的組件是組件配置而非組件，框架后續(xù)會(huì)生成其構(gòu)造函數(shù)，它們基于VueComponent，擴(kuò)展于Vue；

5、vue中常見組件化技術(shù)有：屬性prop，自定義事件，插槽等，它們主要用于組件通信、擴(kuò)展等；

6、合理的劃分組件，有助于提升應(yīng)用性能；

7、組件應(yīng)該是高內(nèi)聚、低耦合的；

8、遵循單向數(shù)據(jù)流的原則。

談一談對(duì)vue設(shè)計(jì)原則的理解？

和上一題的思路一樣，我們首先要明確：關(guān)于VUE設(shè)計(jì)原則，我們要從哪幾個(gè)方面入手進(jìn)行詳細(xì)解答？

而在vue的官網(wǎng)上，就寫著大大的定義和特點(diǎn)：

漸進(jìn)式JavaScript框架

易用、靈活和高效

所以闡述此題的整體思路按照這個(gè)展開即可。

正確解答：

首先就是漸進(jìn)式JavaScript框架：

與其它大型框架不同的是，Vue 被設(shè)計(jì)為可以自底向上逐層應(yīng)用。

Vue 的核心庫只關(guān)注視圖層，不僅易于上手，還便于與第三方庫或既有項(xiàng)目整合。

另一方面，當(dāng)與現(xiàn)代化的工具鏈以及各種支持類庫結(jié)合使用時(shí)，Vue 也完全能夠?yàn)閺?fù)雜的單頁應(yīng)用提供驅(qū)動(dòng)。

易用性

vue提供數(shù)據(jù)響應(yīng)式、聲明式模板語法和基于配置的組件系統(tǒng)等核心特性。

這些使我們只需要關(guān)注應(yīng)用的核心業(yè)務(wù)即可，只要會(huì)寫js、html和css就能輕松編寫vue應(yīng)用。

靈活性

漸進(jìn)式框架的最大優(yōu)點(diǎn)就是靈活性，如果應(yīng)用足夠小，我們可能僅需要vue核心特性即可完成功能；

隨著應(yīng)用規(guī)模不斷擴(kuò)大，我們才可能逐漸引入路由、狀態(tài)管理、vue-cli等庫和工具；

不管是應(yīng)用體積還是學(xué)習(xí)難度都是一個(gè)逐漸增加的平和曲線。

高效性

超快的虛擬 DOM 和 diff 算法使我們的應(yīng)用擁有最佳的性能表現(xiàn)。

追求高效的過程還在繼續(xù)，vue3中引入Proxy對(duì)數(shù)據(jù)響應(yīng)式改進(jìn)以及編譯器中對(duì)于靜態(tài)內(nèi)容編譯的改進(jìn)都會(huì)讓vue更加高效。

對(duì)MVC、MVP和MVVM的理解

當(dāng)我們面對(duì)這道考題時(shí)，往往有些摸不著頭腦，因?yàn)镸VC、MVP和MVVM的知識(shí)點(diǎn)非常廣泛，很難做到說清、說透。

那要怎么才能回答的簡(jiǎn)潔有條理？讓面試官眼前一亮呢？

來聽村長(zhǎng)給你清晰解讀一下這道題的正確思路吧！

其實(shí)在日常工作中，類似MVP、MVC這類前端程序，我們程序員甚至自己都沒用過，這恰恰就反映了：

前端這些年從無到有，從有到優(yōu)的變遷過程。

想到這里，我們的解題思路便慢慢浮出水面了，那就是：

按時(shí)間順序，淺談MVC、MVP、MVVM等系列產(chǎn)品的更新迭代。

Web1.0時(shí)代

在web1.0時(shí)代，并沒有前端的概念。

開發(fā)一個(gè)web應(yīng)用多數(shù)采用：

ASP.NET/Java/PHP編寫，

項(xiàng)目通常由多個(gè)aspx/jsp/php文件構(gòu)成。

每個(gè)文件中同時(shí)包含了HTML、CSS、JavaScript、C#/Java/PHP代碼。

系統(tǒng)整體架構(gòu)可能是這樣子的?：

這種架構(gòu)的好處是簡(jiǎn)單快捷，但是，缺點(diǎn)也非常明顯：JSP代碼難以維護(hù)

為了讓開發(fā)更加便捷，代碼更易維護(hù)，前后端職責(zé)更清晰。便衍生出MVC開發(fā)模式和框架，前端展示以模板的形式出現(xiàn)。

典型的框架就是：

Spring、Structs、Hibernate。

整體框架如圖所示?：

使用這種分層架構(gòu)，職責(zé)清晰，代碼易維護(hù)。

但這里的MVC僅限于后端，前后端形成了一定的分離，前端只完成了后端開發(fā)中的view層。

但是，同樣的這種模式存在著一些問題：

1、前端頁面開發(fā)效率不高

2、前后端職責(zé)不清

web 2.0時(shí)代

自從Gmail的出現(xiàn)，ajax技術(shù)開始風(fēng)靡全球。有了ajax之后，前后端的職責(zé)就更加清晰了。

因?yàn)榍岸丝梢酝ㄟ^Ajax與后端進(jìn)行數(shù)據(jù)交互，因此，整體的架構(gòu)圖也變化成了下面這幅圖?：

通過ajax與后臺(tái)服務(wù)器進(jìn)行數(shù)據(jù)交換，前端開發(fā)人員，只需要開發(fā)頁面這部分內(nèi)容，數(shù)據(jù)可由后臺(tái)進(jìn)行提供。

而且ajax可以使得頁面實(shí)現(xiàn)部分刷新，減少了服務(wù)端負(fù)載和流量消耗，用戶體驗(yàn)也更佳。

這時(shí)，才開始有專職的前端工程師。同時(shí)前端的類庫也慢慢的開始發(fā)展，最著名的就是jQuery了。

當(dāng)然，此架構(gòu)也存在問題：缺乏可行的開發(fā)模式承載更復(fù)雜的業(yè)務(wù)需求，頁面內(nèi)容都雜糅在一起，一旦應(yīng)用規(guī)模增大，就會(huì)導(dǎo)致難以維護(hù)了。

因此，前端的MVC也隨之而來。

前后端分離后的架構(gòu)演變——MVC、MVP和MVVM

MVC

前端的MVC與后端類似，具備著View、Controller和Model。

Model：負(fù)責(zé)保存應(yīng)用數(shù)據(jù)，與后端數(shù)據(jù)進(jìn)行同步

Controller：負(fù)責(zé)業(yè)務(wù)邏輯，根據(jù)用戶行為對(duì)Model數(shù)據(jù)進(jìn)行修改

View：負(fù)責(zé)視圖展示，將model中的數(shù)據(jù)可視化出來。

三者形成了一個(gè)如圖所示的模型：

這樣的模型，在理論上是可行的。但往往在實(shí)際開發(fā)中，并不會(huì)這樣操作。因?yàn)殚_發(fā)過程并不靈活。

例如，一個(gè)小小的事件操作，都必須經(jīng)過這樣的一個(gè)流程，那么開發(fā)就不再便捷了。

在實(shí)際場(chǎng)景中，我們往往會(huì)看到另一種模式，

如圖所示?：

這種模式在開發(fā)中更加的靈活，backbone.js框架就是這種的模式。

但是，這種靈活可能導(dǎo)致嚴(yán)重的問題：

1、數(shù)據(jù)流混亂：如下圖?

2、View比較龐大，而Controller比較單薄：

由于很多的開發(fā)者都會(huì)在view中寫一些邏輯代碼，逐漸的就導(dǎo)致view中的內(nèi)容越來越龐大，而controller變得越來越單薄。

既然有缺陷，就會(huì)有變革。

前端的變化中，似乎少了MVP的這種模式，是因?yàn)锳ngularJS早早地將MVVM框架模式帶入了前端。

MVP模式雖然前端開發(fā)并不常見，但是在安卓等原生開發(fā)中，開發(fā)者還是會(huì)考慮到它。

MVP

MVP與MVC很接近，P指的是Presenter，presenter可以理解為一個(gè)中間人。

它負(fù)責(zé)著View和Model之間的數(shù)據(jù)流動(dòng)，防止View和Model之間直接交流。

我們可以看一下圖示?

我們可以通過看到，presenter負(fù)責(zé)和Model進(jìn)行雙向交互，還和View進(jìn)行雙向交互。

這種交互方式，相對(duì)于MVC來說少了一些靈活，VIew變成了被動(dòng)視圖，并且本身變得很小。雖然它分離了View和Model。

但是應(yīng)用逐漸變大之后，導(dǎo)致presenter的體積增大，難以維護(hù)。

要解決這個(gè)問題，或許可以從MVVM的思想中找到答案。

MVVM

首先，何為MVVM呢？MVVM可以分解成(Model-View-VIewModel)。

ViewModel可以理解為在presenter基礎(chǔ)上的進(jìn)階版。如圖所示??：

ViewModel通過實(shí)現(xiàn)一套數(shù)據(jù)響應(yīng)式機(jī)制自動(dòng)響應(yīng)Model中數(shù)據(jù)變化；

同時(shí)Viewmodel會(huì)實(shí)現(xiàn)一套更新策略自動(dòng)將數(shù)據(jù)變化轉(zhuǎn)換為視圖更新；

通過事件監(jiān)聽響應(yīng)View中用戶交互修改Model中數(shù)據(jù)。

這樣在ViewModel中就減少了大量DOM操作代碼。

MVVM在保持View和Model松耦合的同時(shí)，還減少了維護(hù)它們關(guān)系的代碼，使用戶專注于業(yè)務(wù)邏輯，兼顧開發(fā)效率和可維護(hù)性。

總結(jié)：

這三者都是框架模式，它們?cè)O(shè)計(jì)的目標(biāo)都是為了解決Model和View的耦合問題。

MVC模式出現(xiàn)較早主要應(yīng)用在后端，如Spring MVC、ASP.NET MVC等，在前端領(lǐng)域的早期也有應(yīng)用，如Backbone.js。

它的優(yōu)點(diǎn)是分層清晰，缺點(diǎn)是數(shù)據(jù)流混亂，靈活性帶來的維護(hù)性問題。

MVP模式在是MVC的進(jìn)化形式，Presenter作為中間層負(fù)責(zé)MV通信，解決了兩者耦合問題，但P層過于臃腫會(huì)導(dǎo)致維護(hù)問題。

MVVM模式在前端領(lǐng)域有廣泛應(yīng)用，它不僅解決MV耦合問題，還同時(shí)解決了維護(hù)兩者映射關(guān)系的大量繁雜代碼和DOM操作代碼，在提高開發(fā)效率、可讀性同時(shí)還保持了優(yōu)越的性能表現(xiàn)。

你了解哪些Vue性能優(yōu)化方法？

相對(duì)其他的“陷阱面試題”，這個(gè)問題就顯得友善了很多，只要我們基礎(chǔ)功底扎實(shí)，回答得井井有條并不是難事。

首先，我們要找到VUE性能的現(xiàn)存問題，大部分都是代碼層面的，然后具體的提出代碼層優(yōu)化意見就可以了。

目前我們所知的VUE代碼層優(yōu)化大致為一下11點(diǎn)，村長(zhǎng)已經(jīng)都幫大家整理好了，請(qǐng)大家隨意消化一下：

●路由懶加載

●keep-alive緩存頁面
●使用v-show復(fù)用DOM
●v-for 遍歷避免同時(shí)使用 v-if
●長(zhǎng)列表性能優(yōu)化
●事件的銷毀
●圖片懶加載
●第三方插件按需引入
●無狀態(tài)的組件標(biāo)記為函數(shù)式組件
●子組件分割
●變量本地化

●SSR

下面是針對(duì)這11個(gè)優(yōu)化點(diǎn)給出的具體優(yōu)化方案：

●路由懶加載?

●keep-alive緩存頁面?

●使用v-show復(fù)用DOM?

●v-for 遍歷避免同時(shí)使用 v-if?

●長(zhǎng)列表性能優(yōu)化：

如果列表是純粹的數(shù)據(jù)展示，不會(huì)有任何改變，就不需要做響應(yīng)化?

如果是大數(shù)據(jù)長(zhǎng)列表，可采用虛擬滾動(dòng)，只渲染少部分區(qū)域的內(nèi)容?

參考：

vue-virtual-scroller?

https://github.com/Akryum/vue-virtual-scroller
vue-virtual-scroll-list?

https://github.com/tangbc/vue-virtual-scroll-list

●事件的銷毀：

Vue 組件銷毀時(shí)，會(huì)自動(dòng)解綁它的全部指令及事件監(jiān)聽器，但是僅限于組件本身的事件。

●圖片懶加載：

對(duì)于圖片過多的頁面，為了加速頁面加載速度。

所以很多時(shí)候我們需要將頁面內(nèi)未出現(xiàn)在可視區(qū)域內(nèi)的圖片先不做加載， 等到滾動(dòng)到可視區(qū)域后再去加載。

參考項(xiàng)目：

vue-lazyload?

https://github.com/hilongjw/vue-lazyload

●第三方插件按需引入：

像element-ui這樣的第三方組件庫可以按需引入，避免體積太大。

●無狀態(tài)的組件標(biāo)記為函數(shù)式組件?

●子組件分割

●變量本地化

●服務(wù)端渲染 - SSR

你對(duì)Vue3.0的新特性有沒有了解？

young村長(zhǎng)幫大家總結(jié)了Vue3.0改進(jìn)方向，主要在以下幾點(diǎn)：

●更快

○虛擬DOM重寫

○優(yōu)化slots的生成

○靜態(tài)樹提升

○靜態(tài)屬性提升

○基于Proxy的響應(yīng)式系統(tǒng)

●更小：

○通過搖樹優(yōu)化核心庫體積

●更容易維護(hù)：

○TypeScript + 模塊化

●更加友好

○跨平臺(tái)：編譯器核心和運(yùn)行時(shí)核心與平臺(tái)無關(guān)，使得Vue更容易與任何平臺(tái)（Web、Android、iOS）一起使用

●更容易使用

○改進(jìn)的TypeScript支持，編輯器能提供強(qiáng)有力的類型檢查和錯(cuò)誤及警告

●更好的調(diào)試支持

●獨(dú)立的響應(yīng)化模塊

●Composition API

虛擬 DOM 重寫

期待更多的編譯時(shí)提示來減少運(yùn)行時(shí)開銷，使用更有效的代碼來創(chuàng)建虛擬節(jié)點(diǎn)。

組件快速路徑+單個(gè)調(diào)用+子節(jié)點(diǎn)類型檢測(cè)

?跳過不必要的條件分支

?JS引擎更容易優(yōu)化

詳情見下圖?

優(yōu)化slots生成

vue3中可以單獨(dú)重新渲染父級(jí)和子級(jí)：

?確保實(shí)例正確的跟蹤依賴關(guān)系

?避免不必要的父子組件重新渲染

詳情見下圖?

靜態(tài)樹提升(Static Tree Hoisting)

使用靜態(tài)樹提升，這意味著 Vue 3 的編譯器將能夠檢測(cè)到什么是靜態(tài)的，然后將其提升，從而降低了渲染成本。

?跳過修補(bǔ)整棵樹，從而降低渲染成本

?即使多次出現(xiàn)也能正常工作

詳情見下圖?

靜態(tài)屬性提升

使用靜態(tài)屬性提升，Vue 3打補(bǔ)丁時(shí)將跳過這些屬性不會(huì)改變的節(jié)點(diǎn)。?

基于 Proxy 的數(shù)據(jù)響應(yīng)式

Vue 2的響應(yīng)式系統(tǒng)使用：

Object.defineProperty 的getter 和 setter。

Vue 3 將使用 ES2015 Proxy 作為其觀察機(jī)制，這將會(huì)帶來如下變化：

●組件實(shí)例初始化的速度提高100％

●使用Proxy節(jié)省以前一半的內(nèi)存開銷，加快速度，但是存在低瀏覽器版本的不兼容

●為了繼續(xù)支持 IE11，Vue 3 將發(fā)布一個(gè)支持舊觀察者機(jī)制和新 Proxy 版本的構(gòu)建

高可維護(hù)性

Vue 3 將帶來更可維護(hù)的源代碼。它不僅會(huì)使用 TypeScript，而且許多包被解耦，更加模塊化。

看了上面面試題解答，不知道大家有沒有一些收獲。

村長(zhǎng)這里還要多啰嗦兩句，大家千萬不要只背答案，更要學(xué)會(huì)答題思路和學(xué)習(xí)方法，這樣不管將來遇上什么問題，大家都能做到舉一反三。

往大了說，提升內(nèi)力才是最重要的目標(biāo)，將來不管使用什么語言、框架，你都將輕松駕馭、信手拈來。

機(jī)會(huì)永遠(yuǎn)只留給全力以赴的人，村長(zhǎng)祝大家早日拿到高薪Offer，走上人生巔峰！