1.前端框架的根本意義

1.1 前端框架的好處

最開始學(xué)習(xí)前端框架的時(shí)候(我第一個(gè)框架是 React)并不理解框架能帶來什么,只是因?yàn)榇蠹叶荚谟每蚣?最實(shí)際的一個(gè)用途就是所有企業(yè)幾乎都在用框架,不用框架就 out 了.

隨著使用的深入我逐漸理解到框架的好處:

• 1.組件化: 其中以 React 的組件化最為徹底,甚至可以到函數(shù)級別的原子組件,高度的組件化可以是我們的工程易于維護(hù)、易于組合拓展。
• 2.天然分層: JQuery 時(shí)代的代碼大部分情況下是面條代碼,耦合嚴(yán)重,現(xiàn)代框架不管是 MVC、MVP還是MVVM 模式都能幫助我們進(jìn)行分層，代碼解耦更易于讀寫。
• 3.生態(tài): 現(xiàn)在主流前端框架都自帶生態(tài),不管是數(shù)據(jù)流管理架構(gòu)還是 UI 庫都有成熟的解決方案。

1.2 前端框架的根本意義

簡單來說,前端框架的根本意義是解決了UI 與狀態(tài)同步問題。

在 Vue 中我們?nèi)绻趖odos中添加一條,只需要app4.todos.push({ text: '新項(xiàng)目' }),這時(shí)由于 Vue 內(nèi)置的響應(yīng)式系統(tǒng)會自動幫我們進(jìn)行 UI 與狀態(tài)的同步工作.

如果我們用 JQuery 或者 JS 進(jìn)行操作,免不了一大堆li.appendChild、document.createElement等 DOM 操作,我們需要一長串 DOM 操作保證狀態(tài)與 UI 的同步,其中一個(gè)環(huán)節(jié)出錯(cuò)就會導(dǎo)致 BUG,手動操作的缺點(diǎn)如下：

頻繁操作 DOM 性能低下.

中間步驟過多,易產(chǎn)生 bug且不易維護(hù),而且心智要求較高不利于開發(fā)效率

不管是 vue 的數(shù)據(jù)劫持、Angular 的臟檢測還是 React 的組件級 reRender都是幫助我們解決 ui 與狀態(tài)同步問題的利器。

這也解釋了Backbone作為前端框架鼻祖在之后落寞的原因,Backbone只是引入了 MVC 的思想,并沒有解決 View 與 Modal 同步的問題,相比于現(xiàn)代的三大框架直接操作 Modal 就可以同步 UI 的特性, Backbone 仍然與 JQuery 綁定,在 View 里操作 Dom來達(dá)到同步 UI 的目的，這顯然是不符合現(xiàn)代前端框架設(shè)計(jì)要求的。

2.Vue 如何保證 UI 與狀態(tài)同步

UI 在 MVVM 中指的是 View，狀態(tài)在 MVVM 中指的是 Modal，而保證 View 和 Modal 同步的是 View-Modal。

Vue 通過一個(gè)響應(yīng)式系統(tǒng)保證了View 與 Modal的同步,由于要兼容IE,Vue 選擇了 Object.defineProperty作為響應(yīng)式系統(tǒng)的實(shí)現(xiàn),但是如果不考慮 IE 用戶的話,Object.defineProperty并不是一個(gè)好的選擇target=https%3A%2F%2Fjuejin.im%2Fpost%2F5acd0c8a6fb9a028da7cdfaf)。

我們將用 Proxy 實(shí)現(xiàn)一個(gè)響應(yīng)式系統(tǒng)。

2.1 發(fā)布訂閱中心

一個(gè)響應(yīng)式系統(tǒng)離不開發(fā)布訂閱模式,因?yàn)槲覀冃枰粋€(gè) Dep保存訂閱者,并在 Observer 發(fā)生變化時(shí)通知保存在 Dep 中的訂閱者,讓訂閱者得知變化并更新視圖,這樣才能保證視圖與狀態(tài)的同步。

2.2 監(jiān)聽者的實(shí)現(xiàn)

我們在訂閱器 Dep 中實(shí)現(xiàn)了一個(gè)notify方法來通知相應(yīng)的訂閱這們,然而notify方法到底什么時(shí)候被觸發(fā)呢?

當(dāng)然是當(dāng)狀態(tài)發(fā)生變化時(shí),即 MVVM 中的 Modal 變化時(shí)觸發(fā)通知,然而Dep 顯然無法得知 Modal 是否發(fā)生了變化,因此我們需要?jiǎng)?chuàng)建一個(gè)監(jiān)聽者Observer來監(jiān)聽 Modal, 當(dāng) Modal 發(fā)生變化的時(shí)候我們就執(zhí)行通知操作。

vue 基于Object.defineProperty來實(shí)現(xiàn)了監(jiān)聽者，我們用 Proxy 來實(shí)現(xiàn)監(jiān)聽者.

與Object.defineProperty監(jiān)聽屬性不同, Proxy 可以監(jiān)聽(實(shí)際是代理)整個(gè)對象,因此就不需要遍歷對象的屬性依次監(jiān)聽了,但是如果對象的屬性依然是個(gè)對象,那么 Proxy 也無法監(jiān)聽,所以我們實(shí)現(xiàn)了一個(gè)observify進(jìn)行遞歸監(jiān)聽即可。

2.3 訂閱者的實(shí)現(xiàn)

我們目前已經(jīng)解決了兩個(gè)問題,一個(gè)是如何得知 Modal 發(fā)生了改變(利用監(jiān)聽者 Observer 監(jiān)聽 Modal 對象),一個(gè)是如何收集訂閱者并通知其變化(利用訂閱器收集訂閱者,并用notify通知訂閱者)。

我們目前還差一個(gè)訂閱者（Watcher）

2.4 批量更新的實(shí)現(xiàn)

我們在上一節(jié)中實(shí)現(xiàn)了訂閱者( Watcher),但是其中的update方法是將訂閱者放入了一個(gè)待更新的隊(duì)列中,而不是直接觸發(fā),原因如下:

因此這個(gè)隊(duì)列需要做的是異步且去重,因此我們用 Set作為數(shù)據(jù)結(jié)構(gòu)儲存 Watcher 來去重,同時(shí)用Promise模擬異步更新。

2.5 小結(jié)

我們梳理一下流程, 一個(gè)響應(yīng)式系統(tǒng)是如何做到 UI(View)與狀態(tài)(Modal)同步的?

我們首先需要監(jiān)聽 Modal, 本文中我們用 Proxy 來監(jiān)聽了 Modal 對象,因此在 Modal 對象被修改的時(shí)候我們的 Observer 就可以得知。

我們得知Modal發(fā)生變化后如何通知 View 呢？要知道，一個(gè) Modal 的改變可能觸發(fā)多個(gè) UI 的更新，比如一個(gè)用戶的用戶名改變了，它的個(gè)人信息組件、通知組件等等組件中的用戶名都需要改變，對于這種情況我們很容易想到利用發(fā)布訂閱模式來解決,我們需要一個(gè)訂閱器(Dep)來儲存訂閱者(Watcher),當(dāng)監(jiān)聽到 Modal 改變時(shí),我們只需要通知相關(guān)的訂閱者進(jìn)行更新即可。

那么訂閱者來自哪里呢？其實(shí)每一個(gè)組件實(shí)例對應(yīng)著一個(gè)訂閱者（正因?yàn)橐粋€(gè)組件實(shí)例對應(yīng)一個(gè)訂閱者，才能利用 Dep 通知到相應(yīng)組件，不然亂套了，通知訂閱者就相當(dāng)于間接通知了組件）。

當(dāng)訂閱者得知了具體變化后它會進(jìn)行相應(yīng)的更新,將更新體現(xiàn)在 UI(View)上,至此UI 與 Modal 的同步完成了。

3.響應(yīng)式系統(tǒng)并不是全部

響應(yīng)式系統(tǒng)雖然是 Vue 的核心概念,但是一個(gè)響應(yīng)式系統(tǒng)并不夠.

響應(yīng)式系統(tǒng)雖然得知了數(shù)據(jù)值的變化,但是當(dāng)值不能完整映射 UI 時(shí),我們依然需要進(jìn)行組件級別的 reRender,這種情況并不高效,因此 Vue 在2.0版本引入了虛擬 DOM, 虛擬 DOM進(jìn)行進(jìn)一步的 diff 操作可以進(jìn)行細(xì)粒度更高的操作,可以保證 reReander 的下限(保證不那么慢)。

除此之外為了方便開發(fā)者，vue 內(nèi)置了眾多的指令，因此我們還需要一個(gè) vue 模板解析器.

原作者姓名：sir-fa
原出處：OSCHINA
原文鏈接：你為什么要使用前端框架Vue? - sir-fa的個(gè)人空間 - OSCHINA - 中文開源技術(shù)交流社區(qū)

總結(jié)

以上是生活随笔為你收集整理的vue ui框架_你为什么要使用前端框架Vue?的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。