react18 之 batching

什么是批处理

批处理是指React将多个状态更新组合为单个新渲染，以获得更好的性能

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    setCount(c => c + 1); // 还不会重新渲染
    setFlag(f => !f); // 还不会重新渲染
    // React只会在结束处渲染一次 (这就是batching!)
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

react17 批处理示例（注意观察控制台每次点击事件对应的一次渲染）
react17 非批处理示例（注意观察控制台每次点击事件对应的两次渲染）
对比可以看到，在异步事件中，react17批处理失效了，这正是react18提出自动批处理的由来

什么是自动批处理？

从React 18的createRoot开始（以下说的react18能够批处理都指的默认使用了createRoot），所有更新都会自动批处理，不管它们来自哪里。
这意味着 timeouts, promises, native event处理程序或任何其他事件中的更新将以与React事件中的更新相同的方式进行批处理。我们希望这样可以减少渲染的次数，从而提高应用程序的性能。

react18 使用createRoot批处理示例（注意观察控制台每次点击事件对应的一次渲染）
react18 不使用createRoot的行为示例（注意观察控制台每次点击事件对应的两次渲染）

什么是 unstable_batchedUpdates?

一些React库使用这个非正式的API强制setState在事件处理程序之外进行批处理:

import { unstable_batchedUpdates } from 'react-dom';

 function handleClick() {
    fetchSomething().then(() => {
      unstable_batchedUpdates(()=>{
        setCount((c) => c + 1);
        setFlag((f) => !f);
      })
    });
  }

这个API在18中仍然存在，但它不再是必要的，因为批处理是自动发生的。我们不会在18中删除它，尽管它可能会在未来的主流库不再依赖它的存在后被删除。

如果我不需要批处理呢？

通常，批处理是安全的，但有些代码可能依赖于在状态更改后立即从DOM中读取某些内容。对于这些用例，你可以使用ReactDOM.flushSync()来选择不做批处理:

import { flushSync } from 'react-dom'; // 注意是react-dom，而不是react

function handleClick() {
   flushSync(() => {
     setCounter(c => c + 1);
   });
   console.log('渲染了第1次')
   flushSync(() => {
     setFlag(f => !f);
   });
   console.log('渲染了第2次')
}

使用Hooks要注意什么?

如果使用hook，我们希望自动批处理在绝大多数情况下都能“正常工作”。

使用class组件要注意什么？

请记住，在React事件处理程序期间的更新总是批处理的，因此对于这些更新没有更改。
在class组件的某些边界情况下，这可能是一个问题。
class组件有一个实现特性，可以同步读取事件内部的状态更新。这意味着你能够读取到setState调用之间的状态: 见示例（在/src/app.js中更改REACT_18的值模拟是否使用react18版本）:

state = {
  count: 0,
  flag: false
}
handleClick = () => {
  setTimeout(() => {
    this.setState(({ count }) => ({ count: count + 1 }));
    console.log(this.state);// 拿到上一行更新结果：{ count: 1, flag: false }
    this.setState(({ flag }) => ({ flag: !flag }));
  });
};

在React 18中，情况不再是这样。因为setTimeout中的所有更新都是批处理的，所以React不会同步呈现第一个setState的结果——呈现发生在下一次浏览器计时期间。所以渲染还没有发生：见示例（在/src/app.js中更改REACT_18的值模拟是否使用react18版本）:

state = {
  count: 0,
  flag: false
}
handleClick = () => {
  setTimeout(() => {
    this.setState(({ count }) => ({ count: count + 1 }));
    console.log(this.state);  // 上一行此时并未完成：{ count: 0, flag: false }
    this.setState(({ flag }) => ({ flag: !flag }));
  });
};

如果这是升级到React 18后对你来说是一个阻碍，你可以使用ReactDOM.flushSync来强制更新，但我们建议谨慎使用:

handleClick = () => {
  setTimeout(() => {
    ReactDOM.flushSync(() => {
      this.setState(({ count }) => ({ count: count + 1 }));
    });
    console.log(this.state);// 拿到上一行更新结果：{ count: 1, flag: false }

    this.setState(({ flag }) => ({ flag: !flag }));
  });
};

这个问题不会影响使用hooks的函数组件，因为下一行设置state不会更新到上一行设置State的结果:

function handleClick() {
  setTimeout(() => {
    console.log(count); // 0
    setCount(c => c + 1);
    setCount(c => c + 1);
    setCount(c => c + 1);
    console.log(count); // 依然是0
  }, 1000)

总结：

升级到react18时，有以下更新:

自动批处理建立在使用createRoot的前提
通过flushSync在setState之间读取状态时解决批处理问题
影响:在 timeouts, promises, native event处理程序或任何其他事件内的更新将以与在React事件内的更新相同的方式批处理，而在react17中默认不这样
谨慎使用unstable_batchedUpdates