[[423352]]

最早的時(shí)候頁面是服務(wù)端渲染的，也就是 PHP、JSP 那些技術(shù)，服務(wù)端通過模版引擎填充數(shù)據(jù)，返回生成的 html，交給瀏覽器渲染。那時(shí)候表單會(huì)同步提交，服務(wù)端返回結(jié)果頁面的 html。

后來瀏覽器有了 ajax 技術(shù)，可以異步的請(qǐng)求，服務(wù)端返回 xml 或者 json。ajax 最早是基于 xml 的，這也是它名字的由來。因?yàn)?xml 多了很多沒必要的標(biāo)簽，內(nèi)容比較多，所以后來 json 流行開來。

網(wǎng)頁和服務(wù)端的數(shù)據(jù)交互變成了異步的，可以服務(wù)端返回 json 數(shù)據(jù)，瀏覽器里拼接 html，之后渲染(瀏覽器里面生成 dom 就等同于渲染)。頁面基本沒啥刷新的必要了，于是后來就逐漸演變出了單頁應(yīng)用 SPA(single page application)。

早期開發(fā)頁面的時(shí)候就是基于瀏覽器的 dom api 操作 dom 來做渲染和交互，但是 dom api 比較啰嗦，而且當(dāng)時(shí)瀏覽器的兼容性問題也比較麻煩，不同瀏覽器有不同的寫法。為了簡化 dom 操作和更方便的兼容各種瀏覽器，出現(xiàn)了 jquery 并且迅速流行開來，那個(gè)時(shí)代 jquery 是如日中天的。

我一直習(xí)慣把網(wǎng)頁分為物理層和邏輯層，dom 就算是物理層，jquery 是操作 dom 的一系列工具函數(shù)，也是工作在物理層。

網(wǎng)頁做的事情基本就是拿到數(shù)據(jù)渲染 dom，并且數(shù)據(jù)改變之后更新 dom，這個(gè)流程是通用的，后來逐漸出現(xiàn)了 mvvm 框架，來自動(dòng)把數(shù)據(jù)的變更映射到 dom，不再需要手動(dòng)操作 dom。也就是 vue、react 等現(xiàn)代的前端框架。我把這一層叫做邏輯層。

前端框架除了提供了數(shù)據(jù)驅(qū)動(dòng)視圖變化的功能以外，還支持了 dom 的邏輯劃分，可以把一部分 dom 封裝成組件，組件和組件之間相互組合，構(gòu)成整個(gè)界面。物理層依然是 dom，只是實(shí)現(xiàn)了數(shù)據(jù)到 dom 的自動(dòng)映射之后，我們只需要在邏輯層寫組件就可以了。

現(xiàn)在前端入門也不會(huì)再學(xué)物理層的操作 dom 的 jquery 了，而是直接從 vue、react 這種邏輯層的前端框架開始。

但是也不是說完全不需要 jquery，前端框架主要解決的是數(shù)據(jù)到 dom 的綁定，可以變化以后自動(dòng)更新 dom。如果不需要更新，那么直接操作 dom 即可，比如各種活動(dòng)頁，沒啥數(shù)據(jù)更新，用 jquery 操作 dom 還是很方便。

前端框架是 UI = f(state) 這種聲明式的思想，只需要聲明組件的視圖、組件的狀態(tài)數(shù)據(jù)、組件之間的依賴關(guān)系，那么狀態(tài)改變就會(huì)自動(dòng)的更新 dom。而 jquery 那種直接操作 dom 的工具函數(shù)庫則是命令式的。

對(duì)于視圖的描述這件事 react 和 vue 用了不同的方案，react 是給 js 擴(kuò)展了 jsx 的語法，由 babel 實(shí)現(xiàn)，可以在描述視圖的時(shí)候直接用 js 來寫邏輯，沒啥新語法。而 vue 是實(shí)現(xiàn)了一套 template 的 DSL，引入了插值、指令、過濾器等模版語法，相對(duì)于 jsx 來說更簡潔，template 的編譯器由 vue 實(shí)現(xiàn)。

vue template 是受限制的，只能訪問 data，prop、method，可以靜態(tài)的分析和優(yōu)化，而 react 的 jsx 因?yàn)橹苯邮?js 的語法，動(dòng)態(tài)邏輯比較多，沒法靜態(tài)的做分析和優(yōu)化。

但是 vue template 也不全是好處，因?yàn)楹?js 上下文割裂開來，引入 typescript 做類型推導(dǎo)的時(shí)候就比較困難，需要單獨(dú)把所有 prop、method、data 的類型聲明一遍才行。而 react 的 jsx 本來就是和 js 同一個(gè)上下文，結(jié)合 typescript 就很自然。

所以 vue template 和 react jsx 各有優(yōu)缺點(diǎn)。

前端框架都是數(shù)據(jù)驅(qū)動(dòng)視圖變化的，而這個(gè)數(shù)據(jù)分散在每個(gè)組件中，怎么在數(shù)據(jù)變化以后更新 dom 呢?

數(shù)據(jù)變化的檢測基本只有三種方式：watch、臟檢查、不檢查。

vue 就是基于數(shù)據(jù)的 watch 的，組件級(jí)別通過 Object.defineProperty 監(jiān)聽對(duì)象屬性的變化，重寫數(shù)組的 api 監(jiān)聽數(shù)組元素的變化，之后進(jìn)行 dom 的更新。

angular 則是基于臟檢查，在每個(gè)可能改變數(shù)據(jù)的邏輯之后都對(duì)比下數(shù)據(jù)是否變了，變了的話就去更新 dom。

react 則是不檢查，不檢查難道每次都渲染全部的 dom 么?也不是，不檢查是因?yàn)椴恢苯愉秩镜?dom，而是中間加了一層虛擬 dom，每次都渲染成這個(gè)虛擬 dom，然后 diff 下渲染出的虛擬 dom 是否變了，變了的話就去更新對(duì)應(yīng)的 dom。

這就是前端框架的數(shù)據(jù)驅(qū)動(dòng)視圖變化的三種思路。

vue 是組件級(jí)別的數(shù)據(jù) watch，當(dāng)組件內(nèi)部監(jiān)聽數(shù)據(jù)變化的地方特別多的時(shí)候，一次更新可能計(jì)算量特別大，計(jì)算量大了就可能會(huì)導(dǎo)致丟幀，也就是渲染的卡頓。所以 vue 的優(yōu)化方式就是把大組件拆成小組件，這樣每個(gè)數(shù)據(jù)就不會(huì)有太多的 watcher 了。

react 并不監(jiān)聽數(shù)據(jù)的變化，而是渲染出整個(gè)虛擬 dom，然后 diff。基于這種方案的優(yōu)化方式就是對(duì)于不需要重新生成 vdom 的組件，通過 shouldComponentUpdate 來跳過渲染。

但是當(dāng)應(yīng)用的組件樹特別大的時(shí)候，只是 shouldComponentUpdate 跳過部分組件渲染，依然可能計(jì)算量特別大。計(jì)算量大了同樣可能導(dǎo)致渲染的卡頓，怎么辦呢?

樹的遍歷有深度優(yōu)先和廣度優(yōu)先兩種方式，組件樹的渲染就是深度優(yōu)先的，一般是通過遞歸來做，但是如果能通過鏈表記錄下路徑，就可以變成循環(huán)。變成了循環(huán)，那么就可以按照時(shí)間片分段，讓 vdom 的生成不再阻塞頁面渲染，這就像操作系統(tǒng)對(duì)多個(gè)進(jìn)程的分時(shí)調(diào)度一樣。

這個(gè)通過把組件樹改成鏈表，把 vdom 的生成從遞歸改循環(huán)的功能就是 react fiber。

fiber 節(jié)點(diǎn)相對(duì)于之前的組件節(jié)點(diǎn)來說，沒有了 parent、children 這種屬性，多了 child、sibling、return 屬性。

通過 fiber 鏈表樹，優(yōu)化了渲染的性能。

可以看到 vue 的性能優(yōu)化和 react 的性能優(yōu)化是不一樣的：

vue 是組件級(jí)別的數(shù)據(jù)監(jiān)聽的方案，問題可能出現(xiàn)在一個(gè)屬性太多 watcher 的時(shí)候，所以優(yōu)化思路就是大組件拆分成小組件，保證每個(gè)屬性不要有太多 watcher。

react 不監(jiān)聽、不檢查數(shù)據(jù)變化，每次都渲染生成 vdom，然后進(jìn)行 vdom 的對(duì)比，那么優(yōu)化的思路就是 shouldComponentUpdate 來跳過部分組件的 render，而且 react 內(nèi)部也做了組件樹的鏈表化(fiber)來把遞歸改成可打斷的渲染，按照時(shí)間片來逐漸生成整個(gè) vdom。

組件之間難免要有邏輯的復(fù)用，react 和 vue 有不同的方案：

vue 的組件是 option 對(duì)象的方式，那么邏輯復(fù)用方式很自然可以想到通過對(duì)象屬性的 mixin，vue2 的組件內(nèi)邏輯復(fù)用方案就是 mixin，但是 mixin 很難區(qū)分混入的屬性、方法的來源，比較亂，代碼維護(hù)性差。但也沒有更好的方案。

react 剛開始也是支持 mixin 的，但后來廢棄了。

react 的組件是 class 和 function 兩種形式，那么類似高階函數(shù)的高階組件(high order component)的方式就比較自然，也就是組件套組件，在父組件里面執(zhí)行一部分邏輯，然后渲染子組件。

除了多加一層組件的 HOC 方式以外，沒有邏輯的部分可以直接把那部分 jsx 作為 props 傳入另一個(gè)組件來復(fù)用，也就是 render props。

HOC 和 render props 是 react 的 class 組件支持的兩種邏輯復(fù)用方案。

最開始的 function 組件是沒有狀態(tài)的，只是作為 class 組件渲染的輔助而存在。

但是 HOC 的邏輯復(fù)用方式最終導(dǎo)致了組件嵌套太深，而且 class 內(nèi)部生命周期比較多，邏輯都放在一起導(dǎo)致了組件比較大。

怎么解決 class 組件嵌套深和組件大的問題呢?而且還不能引入破壞性的更新，不然下場可能會(huì)很慘。

于是 react 團(tuán)隊(duì)就瞅準(zhǔn)了 function 組件，能不能在 function 組件里面也支持 state，通過擴(kuò)展一些 api 的方式來支持，也不是破壞性的更新。

function 組件要支持 state，那 state 存在哪里呢?

class 組件節(jié)點(diǎn)有 state，變成 fiber 節(jié)點(diǎn)之后依然有，function 組件本來就沒有 state，那么 fiber 節(jié)點(diǎn)中同樣也沒有。

那在 function 組件的 fiber 節(jié)點(diǎn)中加入 state 不就行了?

于是 react 就在 function 組件的 fiber 節(jié)點(diǎn)中加入了 memorizedState 屬性用來存儲(chǔ)數(shù)據(jù)，然后在 function 組件里面通過 api 來使用這些數(shù)據(jù)，這些 api 被叫做 hooks api。

因?yàn)槭鞘褂?fiber 節(jié)點(diǎn)上的數(shù)據(jù)，就把 api 命名為了 useXxx。

每個(gè) hooks api 都要有自己存放數(shù)據(jù)的地方，怎么組織呢?有兩種方案，一種是 map，一種是數(shù)組。

用 map 的話那么要 hooks api 要指定 key，按照 key 來存取 fiber 節(jié)點(diǎn)中的數(shù)據(jù)。

用數(shù)組的話順序不能變，所以 hooks api 不能出現(xiàn)在 if 等邏輯塊中，只能在頂層。

為了簡化使用， hooks 最終使用了數(shù)組的方式。當(dāng)然，實(shí)現(xiàn)起來用的是鏈表。

每個(gè) hooks api 取對(duì)應(yīng)的 fiber.memoriedState 中的數(shù)據(jù)來用。

hooks api 可以分為 3 類：

第一類是數(shù)據(jù)類的：

• useState：在 fiber.memoriedState 的對(duì)應(yīng)元素中存放數(shù)據(jù)
• useMemo：在 fiber.memoriedState 的對(duì)應(yīng)元素中存放數(shù)據(jù)，值是緩存的函數(shù)計(jì)算的結(jié)果，在 state 變化后重新計(jì)算值
• useCallback：在 fiber.memoriedState 的對(duì)應(yīng)元素中存放數(shù)據(jù)，值是函數(shù)，在 state 變化后重新執(zhí)行函數(shù)，是 useMemo 在值為函數(shù)的場景下的簡化 api，比如 useCallback(fn, [a,b]) 相當(dāng)于 useMemo(() => fn, [a, b])
• useReducer：在 fiber.memoriedState 的對(duì)應(yīng)元素中存放數(shù)據(jù)，值為 reducer 返回的結(jié)果，可以通過 action 來觸發(fā)值的變更
• useRef：在 fiber.memoriedState 的對(duì)應(yīng)元素中存放數(shù)據(jù)，值為 {current: 具體值} 的形式，因?yàn)閷?duì)象不變，只是 current 屬性變了，所以不會(huì)修改。

useState 是存儲(chǔ)值最簡單的方式，useMemo 是基于 state 執(zhí)行函數(shù)并且緩存結(jié)果，相當(dāng)于 vue 的 getter，useCallback 是一種針對(duì)值為函數(shù)的情況的簡化，useReducer 是通過 action 來觸發(fā)值的修改。useRef 包了一層對(duì)象，每次對(duì)比都是同一個(gè)，所以可以放一些不變的數(shù)據(jù)。

不管形式怎么樣，這些 hooks 的 api 的作用都是返回值的。

第二類是邏輯類的：

• useEffect：異步執(zhí)行函數(shù)，當(dāng)依賴 state 變化之后會(huì)再次執(zhí)行，當(dāng)組件銷毀的時(shí)候會(huì)調(diào)用返回的清理函數(shù)
• useLayoutEffect：在渲染完成后同步執(zhí)行函數(shù)，可以拿到 dom

這兩個(gè) hooks api 都是用于執(zhí)行邏輯的，不需要等渲染完的邏輯都可以放到 useEffect 里。

第三類是 ref 轉(zhuǎn)發(fā)專用的：

數(shù)據(jù)可以通過各種方案共享，但是 dom 元素這種就得通過 ref 轉(zhuǎn)發(fā)了，所謂的 ref 轉(zhuǎn)發(fā)就是在父組件創(chuàng)建 ref，然后子組件把元素傳過去。傳過去之前想做一些修改，就可以用 useImperativeHandle 來改。

通過這 3 類 hooks api，以及之后會(huì)添加的更多 hooks api ，函數(shù)組件里面也能做 state 的存儲(chǔ)，也能在一些階段執(zhí)行一段邏輯，是可以替代 class 組件的方案了。

而且更重要的是，hooks api 是傳遞參數(shù)的函數(shù)調(diào)用的形式，可以對(duì) hooks api 進(jìn)一步封裝成功能更強(qiáng)大的函數(shù)，也就是自定義 hooks。通過這種方式就可以做跨組件的邏輯復(fù)用了。

再回頭看一下最開始要解決的 class 組件嵌套過深和組件太大的問題，通過 hooks 都能解決：

• 邏輯擴(kuò)展不需要嵌套 hoc 了，多調(diào)用一個(gè)自定義的 hooks 就行
• 組件的邏輯也不用都寫在 class 里了，完全可以抽離成不同的 hooks

react 通過 function 組件的 hooks api 解決了 class 組件的邏輯復(fù)用方案的問題。(fiber 是解決性能問題的，而 hooks 是解決邏輯復(fù)用問題的)

vue2 中是通過 mixin 的方式來復(fù)用邏輯的，也有組件太大的問題，在 vue3 中也可以通過類似的思路來解決。

為了體驗(yàn)和原生更接近，現(xiàn)在基本都是不刷新頁面的單頁應(yīng)用，都是從服務(wù)端取數(shù)據(jù)然后驅(qū)動(dòng) dom 變化的 瀏覽器渲染(csr)方案。但對(duì)于一些低端機(jī)，仍然需要服務(wù)端渲染(SSR)的方案。但不能回到 jsp、php 時(shí)代的那種模版引擎服務(wù)端渲染了，而是要基于同一個(gè)組件樹，把它渲染成字符串。服務(wù)端渲染和瀏覽器渲染都用同樣的組件代碼，這就是同構(gòu)的方案。

技術(shù)從出現(xiàn)到完善到連帶的周邊生態(tài)的完善是一個(gè)輪回，從最開始服務(wù)端渲染，到了后來的客戶端渲染，然后出現(xiàn)了邏輯層的組件方案，最后又要基于組件方案重新實(shí)現(xiàn)服務(wù)端渲染。其實(shí)物理層的東西一直都沒變，只是邏輯層不斷的一層添加又一層，目的都是為了提高生產(chǎn)效率，降低開發(fā)成本，保證質(zhì)量，這也是技術(shù)發(fā)展的趨勢(shì)。