建站
咨詢
售后
建站咨詢
新聞中心
最早的時候頁面是服務(wù)端渲染的，也就是 PHP、JSP 那些技術(shù)，服務(wù)端通過模版引擎填充數(shù)據(jù)，返回生成的 html，交給瀏覽器渲染。那時候表單會同步提交，服務(wù)端返回結(jié)果頁面的 html。
10年積累的成都網(wǎng)站制作、成都網(wǎng)站設(shè)計經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有類烏齊免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
后來瀏覽器有了 ajax 技術(shù)，可以異步的請求，服務(wù)端返回 xml 或者 json。ajax 最早是基于 xml 的，這也是它名字的由來。因為 xml 多了很多沒必要的標簽，內(nèi)容比較多，所以后來 json 流行開來。
網(wǎng)頁和服務(wù)端的數(shù)據(jù)交互變成了異步的，可以服務(wù)端返回 json 數(shù)據(jù)，瀏覽器里拼接 html，之后渲染（瀏覽器里面生成 dom 就等同于渲染）。頁面基本沒啥刷新的必要了，于是后來就逐漸演變出了單頁應用 SPA（single page application）。
早期開發(fā)頁面的時候就是基于瀏覽器的 dom api 操作 dom 來做渲染和交互，但是 dom api 比較啰嗦，而且當時瀏覽器的兼容性問題也比較麻煩，不同瀏覽器有不同的寫法。
為了簡化 dom 操作和更方便的兼容各種瀏覽器，出現(xiàn)了 jquery 并且迅速流行開來，那個時代 jquery 是如日中天的。
我一直習慣把網(wǎng)頁分為物理層和邏輯層，dom 就算是物理層，jquery 是操作 dom 的一系列工具函數(shù)，也是工作在物理層。
網(wǎng)頁做的事情基本就是拿到數(shù)據(jù)渲染 dom，并且數(shù)據(jù)改變之后更新 dom，這個流程是通用的，后來逐漸出現(xiàn)了 mvvm 框架，來自動把數(shù)據(jù)的變更映射到 dom，不再需要手動操作 dom。也就是 vue、react 等現(xiàn)代的前端框架。我把這一層叫做邏輯層。
前端框架除了提供了數(shù)據(jù)驅(qū)動視圖變化的功能以外，還支持了 dom 的邏輯劃分，可以把一部分 dom 封裝成組件，組件和組件之間相互組合，構(gòu)成整個界面。物理層依然是 dom，只是實現(xiàn)了數(shù)據(jù)到 dom 的自動映射之后，我們只需要在邏輯層寫組件就可以了。
現(xiàn)在前端入門也不會再學物理層的操作 dom 的 jquery 了，而是直接從 vue、react 這種邏輯層的前端框架開始。
但是也不是說完全不需要 jquery，前端框架主要解決的是數(shù)據(jù)到 dom 的綁定，可以變化以后自動更新 dom。如果不需要更新，那么直接操作 dom 即可，比如各種活動頁，沒啥數(shù)據(jù)更新，用 jquery 操作 dom 還是很方便。
前端框架是 UI = f(state) 這種聲明式的思想，只需要聲明組件的視圖、組件的狀態(tài)數(shù)據(jù)、組件之間的依賴關(guān)系，那么狀態(tài)改變就會自動的更新 dom。而 jquery 那種直接操作 dom 的工具函數(shù)庫則是命令式的。
對于視圖的描述這件事 react 和 vue 用了不同的方案，react 是給 js 擴展了 jsx 的語法，由 babel 實現(xiàn)，可以在描述視圖的時候直接用 js 來寫邏輯，沒啥新語法。
而 vue 是實現(xiàn)了一套 template 的 DSL，引入了插值、指令、過濾器等模版語法，相對于 jsx 來說更簡潔，template 的編譯器由 vue 實現(xiàn)。
vue template 是受限制的，只能訪問 data，prop、method，可以靜態(tài)的分析和優(yōu)化，而 react 的 jsx 因為直接是 js 的語法，動態(tài)邏輯比較多，沒法靜態(tài)的做分析和優(yōu)化。
但是 vue template 也不全是好處，因為和 js 上下文割裂開來，引入 typescript 做類型推導的時候就比較困難，需要單獨把所有 prop、method、data 的類型聲明一遍才行。而 react 的 jsx 本來就是和 js 同一個上下文，結(jié)合 typescript 就很自然。
所以 vue template 和 react jsx 各有優(yōu)缺點。
前端框架都是數(shù)據(jù)驅(qū)動視圖變化的，而這個數(shù)據(jù)分散在每個組件中，怎么在數(shù)據(jù)變化以后更新 dom 呢？
數(shù)據(jù)變化的檢測基本只有三種方式：watch、臟檢查、不檢查。
vue 就是基于數(shù)據(jù)的 watch 的，組件級別通過 Object.defineProperty 監(jiān)聽對象屬性的變化，重寫數(shù)組的 api 監(jiān)聽數(shù)組元素的變化，之后進行 dom 的更新。
angular 則是基于臟檢查，在每個可能改變數(shù)據(jù)的邏輯之后都對比下數(shù)據(jù)是否變了，變了的話就去更新 dom。
react 則是不檢查，不檢查難道每次都渲染全部的 dom 么？也不是，不檢查是因為不直接渲染到 dom，而是中間加了一層虛擬 dom，每次都渲染成這個虛擬 dom，然后 diff 下渲染出的虛擬 dom 是否變了，變了的話就去更新對應的 dom。
這就是前端框架的數(shù)據(jù)驅(qū)動視圖變化的三種思路。
vue 是組件級別的數(shù)據(jù) watch，當組件內(nèi)部監(jiān)聽數(shù)據(jù)變化的地方特別多的時候，一次更新可能計算量特別大，計算量大了就可能會導致丟幀，也就是渲染的卡頓。所以 vue 的優(yōu)化方式就是把大組件拆成小組件，這樣每個數(shù)據(jù)就不會有太多的 watcher 了。
react 并不監(jiān)聽數(shù)據(jù)的變化，而是渲染出整個虛擬 dom，然后 diff?；谶@種方案的優(yōu)化方式就是對于不需要重新生成 vdom 的組件，通過 shouldComponentUpdate 來跳過渲染。
但是當應用的組件樹特別大的時候，只是 shouldComponentUpdate 跳過部分組件渲染，依然可能計算量特別大。計算量大了同樣可能導致渲染的卡頓，怎么辦呢？
樹的遍歷有深度優(yōu)先和廣度優(yōu)先兩種方式，組件樹的渲染就是深度優(yōu)先的，一般是通過遞歸來做，但是如果能通過鏈表記錄下路徑，就可以變成循環(huán)。
變成了循環(huán)，那么就可以按照時間片分段，讓 vdom 的生成不再阻塞頁面渲染，這就像操作系統(tǒng)對多個進程的分時調(diào)度一樣。
這個通過把組件樹改成鏈表，把 vdom 的生成從遞歸改循環(huán)的功能就是 react fiber。
fiber 節(jié)點相對于之前的組件節(jié)點來說，沒有了 parent、children 這種屬性，多了 child、sibling、return 屬性。
通過 fiber 鏈表樹，優(yōu)化了渲染的性能。
可以看到 vue 的性能優(yōu)化和 react 的性能優(yōu)化是不一樣的：
vue 是組件級別的數(shù)據(jù)監(jiān)聽的方案，問題可能出現(xiàn)在一個屬性太多 watcher 的時候，所以優(yōu)化思路就是大組件拆分成小組件，保證每個屬性不要有太多 watcher。
react 不監(jiān)聽、不檢查數(shù)據(jù)變化，每次都渲染生成 vdom，然后進行 vdom 的對比，那么優(yōu)化的思路就是 shouldComponentUpdate 來跳過部分組件的 render，而且 react 內(nèi)部也做了組件樹的鏈表化（fiber）來把遞歸改成可打斷的渲染，按照時間片來逐漸生成整個 vdom。
組件之間難免要有邏輯的復用，react 和 vue 有不同的方案：
vue 的組件是 option 對象的方式，那么邏輯復用方式很自然可以想到通過對象屬性的 mixin，vue2 的組件內(nèi)邏輯復用方案就是 mixin，但是 mixin 很難區(qū)分混入的屬性、方法的來源，比較亂，代碼維護性差。但也沒有更好的方案。
react 剛開始也是支持 mixin 的，但后來廢棄了。
react 的組件是 class 和 function 兩種形式，那么類似高階函數(shù)的高階組件（high order component）的方式就比較自然，也就是組件套組件，在父組件里面執(zhí)行一部分邏輯，然后渲染子組件。
除了多加一層組件的 HOC 方式以外，沒有邏輯的部分可以直接把那部分 jsx 作為 props 傳入另一個組件來復用，也就是 render props。
HOC 和 render props 是 react 的 class 組件支持的兩種邏輯復用方案。
最開始的 function 組件是沒有狀態(tài)的，只是作為 class 組件渲染的輔助而存在。
但是 HOC 的邏輯復用方式最終導致了組件嵌套太深，而且 class 內(nèi)部生命周期比較多，邏輯都放在一起導致了組件比較大。
怎么解決 class 組件嵌套深和組件大的問題呢？而且還不能引入破壞性的更新，不然下場可能會很慘。
于是 react 團隊就瞅準了 function 組件，能不能在 function 組件里面也支持 state，通過擴展一些 api 的方式來支持，也不是破壞性的更新。
function 組件要支持 state，那 state 存在哪里呢？
class 組件節(jié)點有 state，變成 fiber 節(jié)點之后依然有，function 組件本來就沒有 state，那么 fiber 節(jié)點中同樣也沒有。
那在 function 組件的 fiber 節(jié)點中加入 state 不就行了？
于是 react 就在 function 組件的 fiber 節(jié)點中加入了 memorizedState 屬性用來存儲數(shù)據(jù)，然后在 function 組件里面通過 api 來使用這些數(shù)據(jù)，這些 api 被叫做 hooks api。
因為是使用 fiber 節(jié)點上的數(shù)據(jù)，就把 api 命名為了 useXxx。
每個 hooks api 都要有自己存放數(shù)據(jù)的地方，怎么組織呢？有兩種方案，一種是 map，一種是數(shù)組。
用 map 的話那么要 hooks api 要指定 key，按照 key 來存取 fiber 節(jié)點中的數(shù)據(jù)。
用數(shù)組的話順序不能變，所以 hooks api 不能出現(xiàn)在 if 等邏輯塊中，只能在頂層。
為了簡化使用， hooks 最終使用了數(shù)組的方式。當然，實現(xiàn)起來用的是鏈表。
每個 hooks api 取對應的 fiber.memoriedState 中的數(shù)據(jù)來用。
hooks api 可以分為 3 類：
第一類是數(shù)據(jù)類的：
- useState：在 fiber.memoriedState 的對應元素中存放數(shù)據(jù)
- useMemo：在 fiber.memoriedState 的對應元素中存放數(shù)據(jù)，值是緩存的函數(shù)計算的結(jié)果，在 state 變化后重新計算值
- useCallback：在 fiber.memoriedState 的對應元素中存放數(shù)據(jù)，值是函數(shù)，在 state 變化后重新執(zhí)行函數(shù)，是 useMemo 在值為函數(shù)的場景下的簡化 api，比如 useCallback(fn, [a,b]) 相當于 useMemo(() => fn, [a, b])
- useReducer：在 fiber.memoriedState 的對應元素中存放數(shù)據(jù)，值為 reducer 返回的結(jié)果，可以通過 action 來觸發(fā)值的變更
- useRef：在 fiber.memoriedState 的對應元素中存放數(shù)據(jù)，值為 {current: 具體值} 的形式，因為對象不變，只是 current 屬性變了，所以不會修改。
useState 是存儲值最簡單的方式，useMemo 是基于 state 執(zhí)行函數(shù)并且緩存結(jié)果，相當于 vue 的 getter，useCallback 是一種針對值為函數(shù)的情況的簡化，useReducer 是通過 action 來觸發(fā)值的修改。useRef 包了一層對象，每次對比都是同一個，所以可以放一些不變的數(shù)據(jù)。
不管形式怎么樣，這些 hooks 的 api 的作用都是返回值的。
第二類是邏輯類的：
- useEffect：異步執(zhí)行函數(shù)，當依賴 state 變化之后會再次執(zhí)行，當組件銷毀的時候會調(diào)用返回的清理函數(shù)
- useLayoutEffect：在渲染完成后同步執(zhí)行函數(shù)，可以拿到 dom
這兩個 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，以及之后會添加的更多 hooks api ，函數(shù)組件里面也能做 state 的存儲，也能在一些階段執(zhí)行一段邏輯，是可以替代 class 組件的方案了。
而且更重要的是，hooks api 是傳遞參數(shù)的函數(shù)調(diào)用的形式，可以對 hooks api 進一步封裝成功能更強大的函數(shù)，也就是自定義 hooks。通過這種方式就可以做跨組件的邏輯復用了。
再回頭看一下最開始要解決的 class 組件嵌套過深和組件太大的問題，通過 hooks 都能解決：
- 邏輯擴展不需要嵌套 hoc 了，多調(diào)用一個自定義的 hooks 就行
- 組件的邏輯也不用都寫在 class 里了，完全可以抽離成不同的 hooks
react 通過 function 組件的 hooks api 解決了 class 組件的邏輯復用方案的問題。（fiber 是解決性能問題的，而 hooks 是解決邏輯復用問題的）
vue2 中是通過 mixin 的方式來復用邏輯的，也有組件太大的問題，在 vue3 中也可以通過類似的思路來解決。
為了體驗和原生更接近，現(xiàn)在基本都是不刷新頁面的單頁應用，都是從服務(wù)端取數(shù)據(jù)然后驅(qū)動 dom 變化的 瀏覽器渲染(csr)方案。但對于一些低端機，仍然需要服務(wù)端渲染(ssr)的方案。
但不能回到 jsp、php 時代的那種模版引擎服務(wù)端渲染了，而是要基于同一個組件樹，把它渲染成字符串。服務(wù)端渲染和瀏覽器渲染都用同樣的組件代碼，這就是同構(gòu)的方案。
技術(shù)從出現(xiàn)到完善到連帶的周邊生態(tài)的完善是一個輪回，從最開始服務(wù)端渲染，到了后來的客戶端渲染，然后出現(xiàn)了邏輯層的組件方案，最后又要基于組件方案重新實現(xiàn)服務(wù)端渲染。
其實物理層的東西一直都沒變，只是邏輯層不斷的一層添加又一層，目的都是為了提高生產(chǎn)效率，降低開發(fā)成本，保證質(zhì)量，這也是技術(shù)發(fā)展的趨勢。
文章名稱：談?wù)勎疫@些年對前端框架的理解
網(wǎng)站網(wǎng)址：http://www.fisionsoft.com.cn/article/dhgepjg.html
