1 引言

setState 是 React 框架最常用的命令，它是用來更新狀態(tài)的，這也是 React 框架劃時代的功能。

但是 setState 函數(shù)是 react 包導(dǎo)出的，他們又是如何與 react-dom react-native react-art 這些包結(jié)合的呢？

通過 how-does-setstate-know-what-to-do 這篇文章，可以解開這個秘密。

2 概述

setState 函數(shù)是在 React.Component 組件中調(diào)用的，所以最自然的聯(lián)想是，更新 DOM 的邏輯在 react 包中實現(xiàn)。

但是 react 卻可以和 react-dom react-native react-art 這些包打配合，甚至與 react-dom/server 配合在服務(wù)端運行，那可以肯定 react 包中不含有 DOM 更新邏輯。

所以可以推斷，平臺相關(guān)的 UI 更新邏輯分布在平臺相關(guān)的包里，react 包只做了代理。

React 引擎不在 react 包里

從 react 0.14 版本之后，引擎代碼就從 react 包中抽離了，react 包僅僅做通用接口抽象。

也就是說，react 包定義了標(biāo)準(zhǔn)的狀態(tài)驅(qū)動模型的 API，而 react-dom react-native react-art 這些包是在各自平臺的具體實現(xiàn)。

各平臺具體的渲染引擎實現(xiàn)被稱為 reconciler，通過這個鏈接可以看到 react-dom react-native react-art 這三個包的 reconciler 實現(xiàn)。

這說明了 react 包僅告訴你 React 擁有哪些語法，而并不關(guān)心如何實現(xiàn)他們，所以我們需要結(jié)合 react 包與 react-xxx 一起使用。

對于 context，react 包僅僅會做如下定義：

// A bit simplified function createContext(defaultValue) {let context = {_currentValue: defaultValue,Provider: null,Consumer: null};context.Provider = {$$typeof: Symbol.for("react.provider"),_context: context};context.Consumer = {$$typeof: Symbol.for("react.context"),_context: context};return context; }

具體用到時，由 react-dom 和 react-native 決定用何種方式實現(xiàn) MyContext.Provider 這個 API。

這也說明了，如果你不同步升級 react 與 react-dom 版本的話，就可能碰到這樣的報錯：fail saying these types are invalid，原因是 API 定義與實現(xiàn)不匹配。

setState 怎么調(diào)用平臺實現(xiàn)

每個平臺對 UI 更新邏輯的實現(xiàn)，會封裝在 updater 函數(shù)里，所以不同平臺代碼會為組件添加各自的 updater 實現(xiàn)：

// Inside React DOM const inst = new YourComponent(); inst.props = props; inst.updater = ReactDOMUpdater;// Inside React DOM Server const inst = new YourComponent(); inst.props = props; inst.updater = ReactDOMServerUpdater;// Inside React Native const inst = new YourComponent(); inst.props = props; inst.updater = ReactNativeUpdater;

不同于 props, updater 無法被直接調(diào)用，因為這個 API 是由 react 引擎在 setState 時調(diào)用的：

// A bit simplified setState(partialState, callback) {// Use the `updater` field to talk back to the renderer!this.updater.enqueueSetState(this, partialState, callback); }

關(guān)系可以這么描述：react -> setState -> updater <- react-dom 等。

Hooks

Hooks 的原理與 setState 類似，當(dāng)調(diào)用 useState 或 useEffect 時，其內(nèi)部調(diào)用如下：

// In React (simplified a bit) const React = {// Real property is hidden a bit deeper, see if you can find it!__currentDispatcher: null,useState(initialState) {return React.__currentDispatcher.useState(initialState);},useEffect(initialState) {return React.__currentDispatcher.useEffect(initialState);}// ... };

ReactDOM 提供了 __currentDispatcher（簡化的說法）:

// In React DOM const prevDispatcher = React.__currentDispatcher; React.__currentDispatcher = ReactDOMDispatcher; let result; try {result = YourComponent(props); } finally {// Restore it backReact.__currentDispatcher = prevDispatcher; }

可以看到，Hooks 的原理與 setState 基本一致，但需要注意 react 與 react-dom 之間傳遞了 dispatch，雖然你看不到。但這個 dispatch 必須對應(yīng)到唯一的 React 實例，這就是為什么 Hooks 不允許同時加載多個 React 實例的原因。

和 updater 一樣，dispatch 也可以被各平臺實現(xiàn)重寫，比如 react-debug-hooks 就重寫了 dispatcher。

由于需要同時實現(xiàn) readContext, useCallback, useContext, useEffect, useImperativeMethods, useLayoutEffect, useMemo, useReducer, useRef, useState，工程量比較浩大，建議了解基本架構(gòu)就足夠了，除非你要深入?yún)⑴c React 生態(tài)建設(shè)。

3 精讀

與其他 React 分析文章不同，本文并沒有過于刨根問題的上來就剖析 reconciler 實現(xiàn)，而是問了一個最基本的疑問：為什么 setState 來自 react 包，但實現(xiàn)卻在 react-dom 里？React 是如何實現(xiàn)這個 magic 的？

通過這個疑問，我們了解了 React 更上層的抽象能力，如何用一個包制定規(guī)范，用 N 包去實現(xiàn)它。

接口的力量

在日常編程中，接口也擁有的強大力量，下面舉幾個例子。

UI 組件跨三端的接口

由于 RN、Weex、Flux 的某些不足，越來越多的人選擇 “一個思想三端實現(xiàn)” 的方式做跨三端的 UI 組件，這樣既兼顧了性能，又可以照顧到平臺差異性，對不同平臺組件細節(jié)做定制優(yōu)化。

要實施這個方案，最大問題就是接口約定。一定要保證三套實現(xiàn)遵循同一套 API 接口，業(yè)務(wù)代碼才可以實現(xiàn) “針對任意一個平臺編寫，自動移植到其他平臺”。

比較常用的做法是，通過一套統(tǒng)一的 API 文件約束，固定組件的輸入輸出，不同平臺的組件做平臺具體實現(xiàn)。這個思想和 React 如出一轍。

當(dāng)然 RN 這些框架本身也是同一接口在不同平臺實現(xiàn)的典型，只是做的不夠徹底，JS 與 Native 的通信導(dǎo)致了性能不如源生。

通用數(shù)據(jù)查詢服務(wù)

通用數(shù)據(jù)查詢服務(wù)也比較流行，通過磨平各數(shù)據(jù)庫語法，讓用戶通過一套 SQL 查詢各種類型數(shù)據(jù)庫的數(shù)據(jù)。

這個方案中，一套通用的查詢語法就類似 React 定義的 API，執(zhí)行階段會轉(zhuǎn)化為各數(shù)據(jù)庫平臺的 SQL 方言。

小程序融合方案

現(xiàn)在這種方案很火。通過基于 template 或者 jsx 的語法，一鍵發(fā)布到各平臺小程序應(yīng)用。

這種方案一定會抽象一套通用語法，甚至幾乎等價與 react 與 react-dom 的關(guān)系：所有符合規(guī)范的語法，轉(zhuǎn)化為各小程序平臺的實現(xiàn)。

4 總結(jié)

這種分平臺實現(xiàn)方案與跨平臺方案還是有很大區(qū)別的，像 JAVA 虛擬機本質(zhì)還是一套實現(xiàn)方案。而分平臺的實現(xiàn)可以帶來最原生的性能與體驗，同樣收到的約束也最大，應(yīng)該其 API 應(yīng)該是所有平臺支持的一個子集。

另外，這種方案不僅可以用于 一套規(guī)范，不同平臺的實現(xiàn)，甚至可以用在 “同一平臺的實現(xiàn)”。

無論是公司還是開源節(jié)界，都有許多重復(fù)的輪子或者平臺，如果通過技術(shù)委員會約定一套平臺的實現(xiàn)規(guī)范，大家都遵循這個規(guī)范開發(fā)平臺，那未來就比較好做收斂，或者說收斂的第一步都是先統(tǒng)一 API 規(guī)范。

留下一個思考題：還有沒有利用 setState 規(guī)范與實現(xiàn)分離的思想案例？歡迎留下你的答案。

討論地址是：精讀《setState 做了什么》 · Issue #122 · dt-fe/weekly

如果你想?yún)⑴c討論，請點擊這里，每周都有新的主題，周末或周一發(fā)布。前端精讀 - 幫你篩選靠譜的內(nèi)容。

來源：https://segmentfault.com/a/1190000017787272

轉(zhuǎn)載于:https://www.cnblogs.com/lalalagq/p/10241717.html

總結(jié)

以上是生活随笔為你收集整理的精读《setState 做了什么》的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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