2021年1月17日星期日

深入剖析setState同步异步机制

关于 setState

setState 的更新是同步还是异步，一直是人们津津乐道的话题。不过，实际上如果我们需要用到更新后的状态值，并不需要强依赖其同步/异步更新机制。在类组件中，我们可以通过this.setState的第二参数、componentDidMount、componentDidUpdate等手段来取得更新后的值；而在函数式组件中，则可以通过useEffect来获取更新后的状态。所以这个问题，其实有点无聊。

不过，既然大家都这么乐于讨论，今天我们就系统地梳理一下这个问题，主要分为两方面来说：

  • 类组件（class-component）的更新机制
  • 函数式组件（function-component）的更新机制

类组件中的 this.setState

在类组件中，这个问题的答案是多样的，首先抛第一个结论：

  • 在legacy模式中，更新可能为同步，也可能为异步；
  • 在concurrent模式中，一定是异步。

问题一、legacy 模式和 concurrent 模式是什么鬼？

  • 通过ReactDOM.render(<App />, rootNode)方式创建应用，则为 legacy 模式，这也是create-react-app目前采用的默认模式；

  • 通过ReactDOM.unstable_createRoot(rootNode).render(<App />)方式创建的应用，则为concurrent模式，这个模式目前只是一个实验阶段的产物，还不成熟。

legacy 模式下可能同步，也可能异步？

是的，这不是玄学，我们来先抛出结论，再来逐步解释它。

  1. 当直接调用时this.setState时，为异步更新；
  2. 当在异步函数的回调中调用this.setState，则为同步更新；
  3. 当放在自定义 DOM 事件的处理函数中时，也是同步更新。

实验代码如下：

class StateDemo extends React.Component { constructor(props) {  super(props)  this.state = {   count: 0  } } render() {  return <div>   <p>{this.state.count}</p>   <button onClick={this.increase}>累加</button>  </div> } increase = () => {  this.setState({   count: this.state.count + 1  })  // 异步的，拿不到最新值  console.log('count', this.state.count)  // setTimeout 中 setState 是同步的  setTimeout(() => {   this.setState({    count: this.state.count + 1   })   // 同步的，可以拿到   console.log('count in setTimeout', this.state.count)  }, 0) } bodyClickHandler = () => {  this.setState({   count: this.state.count + 1  })  // 可以取到最新值  console.log('count in body event', this.state.count) } componentDidMount() {  // 自己定义的 DOM 事件，setState 是同步的  document.body.addEventListener('click', this.bodyClickHandler) } componentWillUnmount() {  // 及时销毁自定义 DOM 事件  document.body.removeEventListener('click', this.bodyClickHandler) }}

要解答上述现象，就必须了解 setState 的主流程，以及 react 中的 batchUpdate 机制。

首先我们来看看 setState 的主流程：

  1. 调用this.setState(newState)；
  2. newState会存入 pending 队列；
    3，判断是不是batchUpdate；
    4，如果是batchUpdate，则将组件先保存在所谓的脏组件dirtyComponents中；如果不是batchUpdate，那么就遍历所有的脏组件，并更新它们。

由此我们可以判定：所谓的异步更新，都命中了batchUpdate，先保存在脏组件中就完事；而同步更新，总是会去更新所有的脏组件。

非常有意思，看来是否命中batchUpdate是关键。问题也随之而来了，为啥直接调用就能命中batchUpdate，而放在异步回调里或者自定义 DOM 事件中就命中不了呢？

这就涉及到一个很有意思的知识点：react 中函数的调用模式。对于刚刚的 increase 函数，还有一些我们看不到的东西，现在我们通过魔法让其显现出来：

increase = () => {  // 开始：默认处于bashUpdate  // isBatchingUpdates = true  this.setState({   count: this.state.count + 1  })  console.log('count', this.state.count)  // 结束  // isBatchingUpdates = false }
 increase = () => {  // 开始：默认处于bashUpdate  // isBatchingUpdates = true  setTimeout(() => {   // 此时isBatchingUpdates已经设置为了false   this.setState({    count: this.state.count + 1   })   console.log('count in setTimeout', this.state.count)  }, 0)  // 结束  // isBatchingUpdates = false }

当 react 执行我们所书写的函数时，会默认在首位设置isBatchingUpdates变量。看到其中的差异了吗？当 setTimeout 执行其回调时，isBatchingUpdates早已经在同步代码的末尾被置为false了，所以没命中batchUpdate。

那自定义 DOM 事件又是怎么回事？代码依然如下：

 componentDidMount() { // 开始：默认处于bashUpdate // isBatchingUpdates = true document.body.addEventListener("click", () => {  // 在回调函数里面，当点击事件触发的时候，isBatchingUpdates早就已经设为false了  this.setState({  count: this.state.count + 1,  });  console.log("count in body event", this.state.count); // 可以取到最新值。 }); // 结束 // isBatchingUpdates = false }

我们可以看到，当componentDidMount跑完时，isBatchingUpdates已经设置为false了，而点击事件后来触发，并调用回调函数时，取得的isBatchingUpdates当然也是false，不会命中batchUpdate机制。

总结：

  • this.setState是同步还是异步，关键就是看能否命中batchUpdate机制
  • 能不能命中，就是看isBatchingUpdates是true还是false
  • 能命中batchUpdate的场景包括：生命周期和其调用函数、React中注册的事件和其调用函数。总之，是React可以"管理"的入口，关键是"入口"。

这里要注意一点：React去加isBatchingUpdate的行为不是针对"函数"，而是针对"入口"。比如setTimeout、setInterval、自定义DOM事件的回调等，这些都是React"管不到"的入口，所以不会去其首尾设置isBatchingUpdates变量。

concurrent 模式一定是异步更新

因为这个东西只在实验阶段，所以要开启 concurrent 模式，同样需要将 react 升级为实验版本，安装如下依赖：

npm install react@experimental react-dom@experimental

其他代码不用变，只更改 index 文件如下：

- ReactDOM.render(<App />, document.getElementById('root'));+ ReactDOM.unstable_createRoot(document.getElementById('root')).render(<App />);

则可以发现：其更新都是异步的，在任何情况下都是如此。

关于函数式组件中 useState 的 setter

在函数式组件中，我们会这样定义状态：

const [count, setCount] = useState(0)

这时候，我们发现当我们无论在同步函数还是在异步回调中调用 setCount 时，打印出来的 count 都是旧值，这时候我们会说：setCount 是异步的。

 const [count, setCount] = useState(0); // 直接调用 const handleStrightUpdate = () => { setCount(1); console.log(count); // 0 }; // 放在setTimeout回调中 const handleSetTimeoutUpdate = () => { setTimeout(() => {  setCount(1);  console.log(count); // 0 }); };

setCount 是异步的，这确实没错，但是产生上述现象的原因不只是异步更新这么简单。原因主要有以下两点：

1，调用 setCount 时，会做合并处理，异步更新该函数式组件对应的 hooks 链表里面的值，然后触发重渲染(re-renders)，从这个角度上来说，setCount确实是一个异步操作；

2，函数式的capture-value特性决定了console.log(count)语句打印的始终是一个只存在于当前帧的常量，所以就算无论 setCount 是不是同步的，这里都会打印出旧值。









原文转载：http://www.shaoqun.com/a/510065.html

跨境电商：https://www.ikjzd.com/

shirley：https://www.ikjzd.com/w/1684

moss：https://www.ikjzd.com/w/1653


关于setStatesetState的更新是同步还是异步，一直是人们津津乐道的话题。不过，实际上如果我们需要用到更新后的状态值，并不需要强依赖其同步/异步更新机制。在类组件中，我们可以通过this.setState的第二参数、componentDidMount、componentDidUpdate等手段来取得更新后的值；而在函数式组件中，则可以通过useEffect来获取更新后的状态。所以这个问题
rakuten：rakuten
e票联：e票联
2020春节阳春春湾石林风景区安排？春湾风石林春节活动时间：2020春节阳春春湾石林风景区安排？春湾风石林春节活动时间
蒸馍 ：蒸馍
2019预计增长91%！可穿戴设备在这个市场大有钱途！：2019预计增长91%！可穿戴设备在这个市场大有钱途！
发帖者 时间：