关闭

React 是否保持 state 更新的顺序?

时间: 2019-12-30阅读: 69标签: React
stackoverflow 有人提问:Does React keep the order for state updates?

我知道 react 的状态更新是异步执行的,为了性能优化,状态是批量更新的。所以你永远不能确信在调用 setState 后状态是否更新了。但是你是否可以确认 setState 调用后状态的更新顺序呢?

比如以下情况:

  • 相同的组件?
  • 不同的组件?

考虑以下按钮点击的例子:

  1. 是否有可能 a 是 false,b 是 true?
class Container extends React.Component {
  constructor(props) {
    super(props);
    this.state = { a: false, b: false };
  }

  render() {
    return <Button onClick={this.handleClick}/>
  }

  handleClick = () => {
    this.setState({ a: true });
    this.setState({ b: true });
  }
}
  1. 是否有可能 a 是 false,b 是 true?
class SuperContainer extends React.Component {
  constructor(props) {
    super(props);
    this.state = { a: false };
  }

  render() {
    return <Container setParentState={this.setState.bind(this)}/>
  }
}

class Container extends React.Component {
  constructor(props) {
    super(props);
    this.state = { b: false };
  }

  render() {
    return <Button onClick={this.handleClick}/>
  }

  handleClick = () => {
    this.props.setParentState({ a: true });
    this.setState({ b: true });
  }
}

请记住,这是我对用例的极端简化。我知道我可以改善我的代码,例如,在例 1 中同时更新两个 state 值,以及在例 2 中的第一个 setState 的回调中执行第二个 setState。但是,这不是我的问题,而且我只想知道 React 执行这些状态更新时有没有确切的方式和顺序,仅此而已。


不久后,React 的作者 Dan Abramov 亲自来回答了。

I work on React.

开场定乾坤。很有力度的一句话。

TLDR:

很多英文文章中都会出现 TLDR,有时候会写成 tl_dr、tl;dr,是 Too Long; Didn’t Read 的缩写,作用就是告诉读者,这篇内容篇幅比较长,如果不想深入探讨或时间有限,可以看总结。

Dan Abramov 先给出了结论:

  • 同一个组件中,setState 是否有确定的顺序?是的
  • 不同组件中,setState 是否有确定的顺序?是的

状态始终是按照特定的顺序更新的。无论你是否看到介于两个状态之间的一个中间状态,无论你是否在批处理内。

目前(React 16 及更早版本),默认情况下,只有 React 事件处理程序中的更新才会被批处理。有一个不稳定(unstable)的 API 来强制在事件处理程序之外进行批处理,以便在需要时处理罕见的情况。

在未来的版本(可能是 React 17 或更高版本)中,React 将默认批量更新所有更新,因此你不必考虑这一点。与往常一样,我们将在 React 博客和 release note 中宣布对此的任何更改。


理解这一点的关键在于,在 React 事件处理程序中,不论 setState() 调用了多少次,也不论 setState() 被多少个组件调用,它们在事件结束时只会生成一次重新渲染。这对于大型应用程序性能至关重要,因为如果 Child 与 Parent 处理 click 事件的时候都调用 setState(),你不希望重新渲染 Child 两次。

在这两个例子中,setState() 调用都发生在 React 事件处理程序中。因此,在事件结束时,他们总是被合并到一起(而且你看不到中间状态)。

更新总是按照它们发生的顺序进行浅合并(shallowly merge)。所以如果第一次更新是 {a: 10},第二次是 {b: 20},第三次 {a: 30},呈现的状态将是 {a: 30, b: **20}。对 state 中同一个 key 的更新(例如我的例子中 a 的更新),最新(近)的更新总是“胜出”。**

当我们在批处理结束时重新呈现 UI 时,this.state 对象已经被更新了。所以如果你需要根据之前的状态更新状态(比如增加一个计数器),你应该使用 setState(fn) 的回掉函数版本来提供之前的状态,而不是读取状态 this.state。如果你对这个理由感到好奇,我在这个评论中深入地解释了它。


在你的例子中,我们不会看到“中间状态”,因为我们在具有批处理功能的 React 事件处理程序中(因为 React “知道”什么时候退出该事件)。

但是,在 React 16 和更早版本中,React 事件处理程序之外还没有默认的批处理。因此,如果在你的例子中,我们吧 handleClick 替换为 AJAX 处理程序,那么每个 setState() 都会立即处理。在这种情况下,是的,你看到一个中间状态:

promise.then(() => {
  // 我们不在事件处理程序中,因此它们都会被刷新。
  this.setState({a: true}); // 使用 {a: true, b: false } 重新渲染
  this.setState({b: true}); // 使用 {a: true, b: true } 重新渲染
  this.props.setParentState(); // 重新渲染父组件
});

我们认识到,根据是否处于事件处理程序中,行为是不同的,这是不方便的。这将在未来的 React 版本中进行更改,默认情况下将批量更新所有更新(并提供选择性 API 以同步刷新更改)。直到我们切换默认行为(可能在 React 17 中),有一个 API 可以用来强制批量处理:

promise.then(() => {
  // 强制批量处理
  ReactDOM.unstable_batchedUpdates(() => {
    this.setState({a: true}); // 不重新渲染
    this.setState({b: true}); // 不重新渲染
    this.props.setParentState(); // 不重新渲染
  });
  // 当我们退出 unstable_batchedUpdates函数后,重新渲染一次
});

在 React 内部,事件处理程序都被包装在 unstable_batchedUpdates 内,这就是默认情况下批处理的原因。请注意,将 setState 封装 unstable_batchedUpdates 两次是不起作用的。当我们退出最外层的unstable_batchedUpdates 调用时,更新被刷新。

该 API 是“不稳定的”,因为如果默认情况下已经启用批处理,我们将删除它。但是,在 React 小版本中我们不会删除它,所以在 React 17 之前,如果你需要在 React 事件处理程序之外的某些情况下强制批处理,你可以安全地依赖它。


总之,这是一个令人困惑的话题,因为 React 默认只在事件处理程序中进行批处理。这将在未来的版本中发生变化,那么行为将更直接。但解决方案不是减少批处理,而是默认开启更多的批处理。这就是我们要做的。


站长推荐

1.云服务推荐: 国内主流云服务商,各类云产品的最新活动,优惠券领取。地址:阿里云腾讯云华为云

2.广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入

链接: http://www.fly63.com/article/detial/10012

关闭

React + Webpack 构建打包优化

React 相关的优化:使用 babel-react-optimize 对 React 代码进行优化,检查没有使用的库,去除 import 引用,按需打包所用的类库,比如 lodash 、echarts 等.Webpack 构建打包存在的问题两个方面:构建速度慢,打包后的文件体积过大

React框架学习_关于React两种构建应用方式选择

一般在传统模式下,我们构建前端项目很简单。就是下载各种js文件,如JQuery、Echart等,直接放置在html静态文件。Webpack则是JavaScript中比较知名的打包工具。这两个构建工具构成了React应用快速搭建的基础。

如果没有virtual dom,react会怎样?

如果react火起来的时候,没有virtual dom,会怎样?你还会选择使用react吗?这是一个历史假设问题。但今天来看,这个问题却非常有趣,因为,在经历对react的狂热追捧之后

React组件的state和props

React 的数据是自顶向下单向流动的,即从父组件到子组件中,组件的数据存储在 props 和 state 中。实际上在任何应用中,数据都是必不可少的,我们需要直接的改变页面上一块的区域来使得视图的刷新

react中PureComponent浅对比策略

PureComponent实现了Component中没有实现的shouComponentUpdata()方法,会对state和props进行一次浅对比,本文介绍一下浅对比策略,源码中,实现浅对比的函数是:shallowEqual()

简单的useState实现

这样的用法和以往的 setState 是有明显的不同的,他看起来更像 redux——我们初始化一个 state,然后 dispatch 一个 action,再由 reducer 改变 state 后返回新的 state。

渐进式React

可以说 React 为Web开发者带来了全新的开发模式,而在各类新功能下,如何达到性能最优仍是我们需要关心的。今天做一次精读尝试,原文地址在文末,话不多说,先呈上一份性能清单:

如何写出漂亮的 React 组件

在Walmart Labs的产品开发中,我们进行了大量的Code Review工作,这也保证了我有机会从很多优秀的工程师的代码中学习他们的代码风格与样式。在这篇博文里我会分享出我最欣赏的五种组件模式与代码片。不过我首先还是要谈谈为什么我们需要执着于提高代码的阅读体验

React新Context API在前端状态管理的实践

众所周知,React的单向数据流模式导致状态只能一级一级的由父组件传递到子组件,在大中型应用中较为繁琐不好管理,通常我们需要使用Redux来帮助我们进行管理,然而随着React 16.3的发布,新context api成为了新的选择。

必须要会的 50 个React 面试题

如果你是一位有抱负的前端程序员并准备面试,那么这篇文章很适合你。本文是你学习和面试 React 所需知识的完美指南。JavaScript 工具缓慢而稳定地在市场中扎根,对 React 的需求呈指数级增长。选择合适的技术来开发应用或网站变得越来越有挑战性

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!