022.setState如何知道該做什么？ · 每天一道面試題

當你在組件中調用`setState`的時候，你認為發生了些什么？ ~~~jsx import React from 'react'; import ReactDOM from 'react-dom'; class Button extends React.Component { constructor(props) { super(props); this.state = { clicked: false }; this.handleClick = this.handleClick.bind(this); } handleClick() { this.setState({ clicked: true }); } render() { if (this.state.clicked) { return <h1>Thanks</h1>; } return ( <button onClick={this.handleClick}> Click me! </button> ); } } ReactDOM.render(<Button />, document.getElementById('container')); ~~~ 當然是：React根據下一個狀態`{clicked：true}`重新渲染組件，同時更新DOM以匹配返回的`<h1>Thanks</ h1>`元素啊。看起來很直白。但是等等，是*React*做了這些嗎？還是*React DOM*？更新DOM聽起來像是React DOM的職責所在。但是我們調用的是`this.setState()`，而沒有調用任何來自React DOM的東西。而且我們組件的父類`React.Component`也是在React本身定義的。所以存在于`React.Component`內部的`setState()`是如何更新DOM的呢？ **免責聲明: 就像本博客里[絕大多數](https://overreacted.io/zh-hans/why-do-react-elements-have-typeof-property/)[其他的](https://overreacted.io/zh-hans/how-does-react-tell-a-class-from-a-function/)[帖子](https://overreacted.io/zh-hans/why-do-we-write-super-props/)一樣，其實你不*需要*知道其中的任何知識，就可以有效地使用React。本文面向的是那些想要了解React背后原理的人。而這完全是可選的！** 我們或許會認為：`React.Component`類包含了DOM更新的邏輯。但是如果是這樣的話，`this.setState()`又如何能在其他環境下使用呢？舉個例子，React Native app中的組件也是繼承自`React.Component`。他們依然可以像我們在上面做的那樣調用`this.setState()`，而且React Native渲染的是安卓和iOS原生的界面而不是DOM。你或許對React Test Renderer 或是 Shallow Renderer很熟悉。這些測試策略能讓你正常渲染組件，也可以在組件內部調用`this.setState()`。但是這兩個渲染器并不與DOM相關。如果你曾使用過一些渲染器像[React ART](https://github.com/facebook/react/tree/master/packages/react-art)，你也許也知道在一個頁面中我們是可以使用多個渲染器的。（舉個例子，ART 組件在React DOM樹的內部起作用。）這使得全局標志或變量無法維持。因此，**`React.Component`以某種未知的方式將處理狀態（state）更新的任務委托給了特定平臺的代碼。**在我們理解這些是如何發生的之前，讓我們深挖一下包（packages）是如何分離的以及為什么這樣分離。 > 有一個很常見的誤解就是React“引擎” 是存在于`react`包里面的。然而事實并非如此。 >實際上從[React 0.14](https://reactjs.org/blog/2015/07/03/react-v0.14-beta-1.html#two-packages)我們將代碼拆分成多個包以來，`react`包故意只暴露一些定義組件的API。絕大多數React的*實現*都存在于“渲染器（renderers）”中。 `react-dom`、`react-dom/server`、`react-native`、`react-test-renderer`、`react-art`都是常見的渲染器（當然你也可以[創建屬于你的渲染器](https://github.com/facebook/react/blob/master/packages/react-reconciler/README.md#practical-examples)）。這就是為什么不管你的目標平臺是什么，`react`包都是可用的。從`react`包中導出的一切，比如`React.Component`、`React.createElement`、`React.Children`和（最終的）[Hooks](https://reactjs.org/docs/hooks-intro.html)，都是獨立于目標平臺的。無論你是運行React DOM，還是 React DOM Server,或是 React Native，你的組件都可以使用同樣的方式導入和使用。相比之下，渲染器包暴露的都是特定平臺的API，比如說：`ReactDOM.render()`，可以讓你將React層次結構（hierarchy）掛載進一個DOM節點。每一種渲染器都提供了類似的API。理想狀況下，絕大多數*組件*都不應該從渲染器中導入任何東西。只有這樣，組件才會更加靈活。 **和大多數人現在想的一樣，React “引擎”就是存在于各個渲染器的內部。**很多渲染器包含一份同樣代碼的復制 —— 我們稱為[“協調器”(“reconciler”)](https://github.com/facebook/react/tree/master/packages/react-reconciler)。[構建步驟(build step)](https://reactjs.org/blog/2017/12/15/improving-the-repository-infrastructure.html#migrating-to-google-closure-compiler)將協調器代碼和渲染器代碼平滑地整合成一個高度優化的捆綁包（bundle）以獲得更高的性能。（代碼復制通常來說不利于控制捆綁包的大小，但是絕大多數React用戶同一時間只會選用一個渲染器，比如說`react-dom`。）這里要注意的是：`react`包僅僅是讓你*使用* React 的特性，但是它完全不知道這些特性是*如何*實現的。而渲染器包(`react-dom`、`react-native`等)提供了React特性的實現以及平臺特定的邏輯。這其中的有些代碼是共享的(“協調器”)，但是這就涉及到各個渲染器的實現細節了。現在我們知道為什么當我們想使用新特性時，`react`和`react-dom`*都*需要被更新。舉個例子，當React 16.3添加了Context API，`React.createContext()`API會被React包暴露出來。但是`React.createContext()`其實并沒有*實現*context。因為在React DOM 和 React DOM Server 中同樣一個 API 應當有不同的實現。所以`createContext()`只返回了一些普通對象： ~~~jsx // 簡化版代碼 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; } ~~~ 當你在代碼中使用`<MyContext.Provider>`或`<MyContext.Consumer>`的時候，是*渲染器*決定如何處理這些接口。React DOM也許用某種方式追蹤context的值，但是React DOM Server用的可能是另一種不同的方式。 **所以，如果你將`react`升級到了16.3+，但是不更新`react-dom`，那么你就使用了一個尚不知道`Provider`和`Consumer`類型的渲染器。**這就是為什么一個老版本的`react-dom`會[報錯說這些類型是無效的](https://stackoverflow.com/a/49677020/458193)。同樣的警告也會出現在React Native中。然而不同于React DOM的是，一個React新版本的發布并不立即“強制”發布新的 React Native 版本。他們具有獨立的發布日程。每隔幾周，更新后的渲染器代碼就會[單獨同步到](https://github.com/facebook/react-native/commits/master/Libraries/Renderer/oss)React Native倉庫。這就是相比 React DOM，React Native 特性可用時間不同的原因。 * * * 好吧，所以現在我們知道了`react`包并不包含任何有趣的東西，除此之外，具體的實現也是存在于`react-dom`，`react-native`之類的渲染器中。但是這并沒有回答我們的問題。`React.Component`中的`setState()`如何與正確的渲染器“對話”？ > 答案是：每個渲染器都在已創建的類上設置了一個特殊的字段。**這個字段叫做`updater`。這并不是*你*要設置的的東西——而是，React DOM、React DOM Server 或 React Native在創建完你的類的實例之后會立即設置的東西： ~~~jsx // React DOM 內部 const inst = new YourComponent(); inst.props = props; inst.updater = ReactDOMUpdater; // React DOM Server 內部 const inst = new YourComponent(); inst.props = props; inst.updater = ReactDOMServerUpdater; // React Native 內部 const inst = new YourComponent(); inst.props = props; inst.updater = ReactNativeUpdater; ~~~ 查看[`React.Component`中`setState`的實現](https://github.com/facebook/react/blob/ce43a8cd07c355647922480977b46713bd51883e/packages/react/src/ReactBaseClasses.js#L58-L67)，`setState`所做的一切就是**委托渲染器創建這個組件的實例**： ![](https://img.kancloud.cn/c3/65/c36596a9ad922d74a5a567c98611faf4_1488x420.png) ~~~jsx // 適當簡化的代碼 setState(partialState, callback) { // 使用`updater`字段回應渲染器！ this.updater.enqueueSetState(this, partialState, callback); } ~~~ React DOM Server[也許想](https://github.com/facebook/react/blob/ce43a8cd07c355647922480977b46713bd51883e/packages/react-dom/src/server/ReactPartialRenderer.js#L442-L448)忽略一個狀態更新并且警告你，而React DOM 與 React Native卻想要讓他們協調器（reconciler）的副本[處理它](https://github.com/facebook/react/blob/ce43a8cd07c355647922480977b46713bd51883e/packages/react-reconciler/src/ReactFiberClassComponent.js#L190-L207)。 > 這就是this.setState()`盡管定義在React包中，卻能夠更新DOM的原因。它讀取由React DOM設置的`this.updater`，讓React DOM安排并處理更新。 * * * 現在關于類的部分我們已經知道了，那關于Hooks的呢？當人們第一次看見[Hooks proposal API](https://reactjs.org/docs/hooks-intro.html)，他們可能經常會想：`useState是`怎么 “知道要做什么”的？然后假設它比那些包含`this.setState()`的`React.Component`類更“神奇”。但是正如我們今天所看到的，基類中`setState()`的執行一直以來都是一種錯覺。它除了將調用轉發給當前的渲染器外，什么也沒做。`useState`Hook[也是做了同樣的事情](https://github.com/facebook/react/blob/ce43a8cd07c355647922480977b46713bd51883e/packages/react/src/ReactHooks.js#L55-L56)。 > **Hooks使用了一個“dispatcher”對象，代替了`updater`字段。**當你調用`React.useState()`、`React.useEffect()`、或者其他內置的Hook時，這些調用被轉發給了當前的dispatcher。 ~~~jsx // React內部(適當簡化) const React = { // 真實屬性隱藏的比較深，看你能不能找到它！ __currentDispatcher: null, useState(initialState) { return React.__currentDispatcher.useState(initialState); }, useEffect(initialState) { return React.__currentDispatcher.useEffect(initialState); }, // ... }; ~~~ 各個渲染器會在渲染你的組件之前設置dispatcher： ~~~jsx // React DOM 內部 const prevDispatcher = React.__currentDispatcher; React.__currentDispatcher = ReactDOMDispatcher;let result; try { result = YourComponent(props); } finally { // 恢復原狀 React.__currentDispatcher = prevDispatcher;} ~~~ 舉個例子， React DOM Server的實現是在[這里](https://github.com/facebook/react/blob/ce43a8cd07c355647922480977b46713bd51883e/packages/react-dom/src/server/ReactPartialRendererHooks.js#L340-L354)，還有就是React DOM 和 React Native共享的協調器的實現在[這里](https://github.com/facebook/react/blob/ce43a8cd07c355647922480977b46713bd51883e/packages/react-reconciler/src/ReactFiberHooks.js)。這就是為什么像`react-dom`這樣的渲染器需要訪問那個你調用Hooks的`react`包。否則你的組件將不會“看見”dispatcher！如果在一個組件樹中存在[React的多個副本](https://github.com/facebook/react/issues/13991)，也許并不會這樣。但是，這總是導致了一些模糊的錯誤，因此Hooks會強迫你在出現問題之前解決包的重復問題。在高級工具用例中，你可以在技術上覆蓋dispatcher，盡管我們不鼓勵這種操作。（對于`__currentDispatcher`這個名字我撒謊了，但是你可以在React倉庫中找到真實的名字。）比如說， React DevTools將會使用[一個專門定制的dispatcher](https://github.com/facebook/react/blob/ce43a8cd07c355647922480977b46713bd51883e/packages/react-debug-tools/src/ReactDebugHooks.js#L203-L214)通過捕獲JavaScript堆棧跟蹤來觀察Hooks樹。*請勿模仿。* 這也意味著Hooks本質上并沒有與React綁定在一起。如果未來有更多的庫想要重用同樣的原生的Hooks, 理論上來說dispatcher可以移動到一個分離的包中，然后暴露成一個一等（first-class）的API，然后給它起一個不那么“嚇人”的名字。但是在實踐中，我們會盡量避免過早抽象，直到需要它為止。 `updater`字段和`__currentDispatcher`對象都是稱為*依賴注入*的通用編程原則的形式。在這兩種情況下，渲染器將諸如`setState`之類的功能的實現“注入”到通用的React包中，以使組件更具聲明性。使用React時，你無需考慮這其中的原理。我們希望React用戶花更多時間考慮他們的應用程序代碼，而不是像依賴注入這樣的抽象概念。但是如果你想知道`this.setState()`或`useState()`是如何知道該做什么的，我希望這篇文章會有所幫助。 ## 摘自 [ setState如何知道該做什么？](https://overreacted.io/zh-hans/how-does-setstate-know-what-to-do/)