React 的 setState 是同步还是异步? |
您所在的位置:网站首页 › settimeout调用函数 › React 的 setState 是同步还是异步? |
setState 是同步还是异步? 肯定是异步的呀。 确定么?那看一下这段代码会打印什么: import { Component } from 'react';class Dong extends Component { constructor() { super(); this.state = { count: 0 } } componentDidMount() { setTimeout(() => { this.setState({ count: 1 }); console.log(this.state.count); this.setState({ count: 2 }); console.log(this.state.count); }); } render() { console.log('render:', this.state.count); return {this.state.count}; }}在 setTimeout 里修改了两次 state,并打印了 state 的值。 如果是异步的,那应该打印的时候 count 还没修改,依然是 0,所以打印两次 0。 然后初始化渲染一次,setState 后再渲染一次,应该 render 两次,count 分别为 0 和 2。 按照异步的方式来分析,确实应该是这样的。 我们执行一下: 会发现两次打印分别是 1 和 2,也就是说 setState 同步修改了 state,然后每次都触发了渲染,所以一共 render 3 次,分别是 0、1、2。 那这么说 setState 是同步的? 确定么?那看下这段代码会打印什么? class Dong extends Component { constructor() { super(); this.state = { count: 0 } } componentDidMount() { this.setState({ count: 1 }); console.log(this.state.count); this.setState({ count: 2 }); console.log(this.state.count); this.setState({ count: 3 }); console.log(this.state.count); } render() { console.log('render:', this.state.count); return {this.state.count}; }}如果 setState 是同步的,那执行完就会修改 state,应该分别打印 1、2、3,然后触发三次 render,加上最开始的一次,一共四次,打印 0、1、2、3。 我们来执行一下: 三次打印都是 0,这说明 setState 是异步的。而且三次 setState 只触发了一次 render,加上最开始的 render,一共两次,打印 0、3。 什么鬼,怎么又是异步的了? 而且不止 class 组件的 setState 是这样,换成 function 组件的 useState 也是一样的: 比如修改三次 state,只会 render 一次: 而在 setTimeout 里,每次修改 state 都会 render: 是不是有点晕,什么情况下 setState 是同步的,什么情况下是异步的呢? 这要从源码找答案了,我们来读一下 setState 的源码。 首先理一下 React 渲染的流程: React 渲染流程react 通过 jsx 来描述界面,jsx 可以通过 babel 等编译器编译成 render function,然后执行后产生 vdom: 这个 vdom 也不是直接渲染的,而是会先转化为 fiber,之后再渲染。 因为 vdom 里每个节点只记录了子节点(children),没有记录兄弟节点,所以必须一次性渲染完,不能打断。 而转成 fiber 的链表结构就会记录父节点(return)、子节点(child)、兄弟节点(sibling),就变成了可打断的。 这里的 vdom 是 React Element 对象: 转化为 fiber 之后是 FiberNode 的对象: 从 vdom 转换成 fiber 的过程就叫做 reconcile,转换过程中会顺便创建对应的 dom 元素,然后全部转换完后一次性 commit 到 dom。 这个过程不是一次性的,是通过 scheduler 调度执行的,那也就可以分批次进行,也就是可打断的含义。 这就是 React 的 fiber 架构下的渲染流程。 理论说完了,我们来对应到源码看一下(这里看的是 v17 的源码): react 把 schedule 和 reconcile 叫做 render 阶段,这个阶段就是把 vdom 转为 fiber。(schedule 只是让 reconcile 可以分多次执行,可以打断,但做的事情是不变的,所以 schedule 也是 render 阶段的一部分) 之后把 fiber 更新到 dom 的过程就叫做 commit 阶段。 对应到源码里就是这样的: 这个 performSyncWorkOnRoot 就是渲染的入口,就像之前所说的,会先执行 render 阶段,把 vdom 转成 fbier,然后再执行 commit,更新到 dom。 render 阶段会执行一个调度的 loop: 这个 loop 就是不断地处理一个个 fiber 的 reconcile: 每个节点都有 beginWork 和 completeWork 两个阶段,因为要做 vdom 转 fiber,而 vdom 是一个树形结构,需要递归处理: 具体不同节点的 reconcile 逻辑不同: 比如函数组件会被调用,拿到 render 出的 vdom 继续进行 reconcile: 比如 class 组件会创建实例,调用 render 方法,拿到 vdom,然后再继续 renconcileChildren。 总之,vdom 转 fiber 是一个递归进行的过程。 之后再进行 commit 阶段。 整个渲染流程的入口就是 performSyncWorkOnRoot 函数。 渲染的流程讲完了,接下来就是 setState 怎么触发渲染的流程了: setState 的流程我们知道了渲染的入口就是 performSyncWorkOnRoot 函数,那 setState 修改完状态,触发一下这个函数不就行了? 确实是这样的。setState 会调用 dispathAction,创建一个 update 对象放到 fiber 节点的 updateQueue 上,然后调度渲染: 调度更新自然就是调度上面说的那个 performSyncWorkOnRoot 函数: react 会先从触发 update 的 fiber 往上找到根 fiber 节点,然后再调用 performSyncWorkOnRoot 的函数进行渲染: 这就是 setState 之后触发重新渲染的实现。 而 setState 是同步还是异步,也就是在这一段控制的。 我们看到判断条件里有个 excutionContext,这个是用来标识当前环境的,比如是批量还是非批量,是否执行过 render 阶段、commit 阶段。 其实在 ReactDOM.render 执行的时候会先调用 unbatchUpdates 函数: 这个函数会在 excutionContext 中设置一个 unbatach 的 flag: 这样在 update 的时候,就会立刻执行 performSyncWorkOnRoot 来渲染。因为首次渲染的时候是马上就要渲染的,没必要调度。 之后走到 commit 阶段会设置一个 commit 的 flag: 然后再次 setState 就不会走到 unbatch 的分支了。 那为什么 setTimeout 里面的 setState 会同步执行呢? 因为直接从 setTimeout 执行的异步代码是没有设置 excutionContext 的,那就会走到 NoContext 的分支,会立刻渲染。(这里的 flush 最终会调用 performSyncWorkOnRoot 函数来渲染): 有什么办法能让 setTimeout 里执行的函数也有 excutionContext 呢? 其实 react17 暴露了 batchUpdates 的 api,用它包裹下,里面的 setState 就会批量执行了: 它的源码其实就是设置了下 excutionContext: 这样等 setState 全部执行完之后再 flush,调用 peformSyncWorkOnRoot 渲染,效果就是批量的 setState 了。 其实按理来说 setState 不能叫异步,还是在同一个调用栈执行的,只不过顺序不同而已。只能叫批量还是非批量。 在 react17 中是这么处理的,如果是 react18,使用 createRoot 的 api 的话,就不会有这种问题了,就算是 setTimeout 里的代码也能批量执行, 而且为了兼容 react17 这种情况,还做了特殊处理,当没有开启并发模式,也就是还是用 ReactDOM.render 的 api 时,没有指定 excutionContext 还会立刻渲染: 等 react 18 普及以后,所有的 setState 都是批量的了,就不会再有批量还是非批量的问题。 总结虽然我们讨论的是 setState 的同步异步,但这个不是 setTimeout、Promise 那种异步,只是指 setState 之后是否 state 马上变了,是否马上 render。 我们梳理了下 React 的渲染流程,包括 render 阶段、commit 阶段,render 阶段是从 vdom 转 fiber,包含 schedule 和 reconcile,commit 阶段是把 fiber 更新到 dom。渲染流程的入口是 performSyncWorkOnRoot 函数。 setState 会创建 update 对象挂到 fiber 对象上,然后调度 performSyncWorkOnRoot 重新渲染。 在 react17 中,setState 是批量执行的,因为执行前会设置 executionContext。但如果在 setTimeout、事件监听器等函数里,就不会设置 executionContext 了,这时候 setState 会同步执行。可以在外面包一层 batchUpdates 函数,手动设置下 excutionContext 来切换成异步批量执行。 在 react18 里面,如果用 createRoot 的 api,就不会有这种问题了。 setState 是同步还是异步这个问题等 react18 普及以后就不会再有了,因为所有的 setState 都是异步批量执行了。 原文始发于微信公众号(神光的编程秘籍):React 的 setState 是同步还是异步? 版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。 文章由半码博客整理,本文链接:https://www.bmabk.com/index.php/post/54534.html |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |