13

为什么 React 中没有异步 getState 函数？

文档告诉我们 setState 是异步的。很好，但这意味着我们不能安全地使用 this.state并且我们还需要一个异步 getState 来尊重执行顺序。

据我了解，我们永远不应该使用 this.state 并使用这样的 getState 函数：

  getState(callback) {
    this.setState((prevState) => {
      callback(prevState) ;
    });
  }
  ...
  this.getState((curState) => {
    // we now can use the current state safely
  }

我的思维方式在这里遗漏了什么？为什么 React 中不存在这样的功能？

- 编辑 -

正如我的一个朋友告诉我的那样，这并不清楚，因为我不相信但第一个答案，让我们分析一些代码：

simpleFunc() {
    setState({ "counter" : 1 });
    setState({ "counter" : 2 });
    this.state.counter // => no garanty about the value
    getState((curState) => {  // ensure curState.counter is 2 });
}

这个简单的例子表明我们不能在所有情况下都直接使用 this.state，因为 setState 是异步的。

这是一个可以使用 getState 的反例： http ://codepen.io/Epithor/pen/ZLavWR?editors=0010#0

简短的回答：不好的做法，甚至不确定 getState 给我们当前

解决方法很简单，但是我们可以分解一些函数并在不关心上下文的情况下使用它们这一事实似乎很有趣，不是吗？

因此，当许多事件以特定顺序发生时，有些事件会更改状态，有些会读取状态：您如​​何确定，当事件读取状态时使用this.state读取良好状态，因为所有更改都是异步的？

事实上，一切都是关于时间的：

T     : event 1, change state
T+1ms : event 2, change state
T+2ms : event 3, read state
T+3ms : event 4, change state

由于您无法预测事件 1 或 2 的 setState 究竟何时会发生，您如何保证事件 3 将真正读取事件 2 中设置的状态？

简短的回答：事件在 JS 堆栈中排队，而状态更改在内部 React 队列中排队。在伸出手之前，内部 React 队列已完全取消堆叠。

4

3 回答 3

27

一般情况下你绝对可以this.state直接使用。你不应该直接改变状态（），而是在你想改变状态时使用。this.state.foo = 0setState

通常setState看起来像这样：

this.setState({
    foo: 0
})

然后你可以安全地在你的函数中使用this.state.fooeg 。render()

但是有一个警告，由于 的异步性质setState，您无法保证在被调用this.state后立即访问。setState

myFunc(baz) {
    this.setState({
        foo: baz + 1
    })
    console.log(this.state.foo) // not guaranteed
}

最好做

myFunc(baz) {
    const bazOne = baz + 1
    this.setState({
        foo: bazOne
    })
    console.log(bazOne)
}

或者使用setStatefunctions第二个参数，用作setState操作完成时执行的回调。在该回调中，您将可以访问更新的状态，即this.state：

myFunc(baz) {
    this.setState({ foo: baz + 1 }, () => {
        console.log(this.state.foo) // guaranteed in callback
    });
}

见：https ://facebook.github.io/react/docs/react-component.html#setstate

于 2017-01-27T21:19:50.940 回答
5

setState 是异步的，因此您无法立即访问您更改的属性，但是，在某些情况下您希望在状态更改后执行操作，在这些情况下您可以执行以下操作：

...

this.state = {
  x = 1
}

...

this.setState({
  x = 2
}, () => {
  console.log(this.state.x) // outputs 2
});

setState 函数在排队的滴答声中调用，因此您可能会排队 x 个 setState，它们都将在下一个滴答声中执行。

于 2017-01-29T12:07:15.393 回答
5

它实际上不是一个错误/问题，而是一个架构决定：state它不打算用作简单的属性/变量/存储，它专门用于界面/视觉状态，因此不需要每次通话都会更新。它使用内部队列，因此如果您在渲染前多次交换状态，它实际上只会用最终值更新一次，并且在render调用 time 方法时，它将包含正确的值。

如果您只需要在执行期间或在同一阶段（例如componentWillReceiveProps和）运行的方法之间存储/检索信息，您可以像往常一样安全地使用：shouldComponentUpdatethis.anyProperty

componentWillReceiveProps() {
  this.value = 'guaranteed';
  return true;
}
shouldComponentUpdate() {
  if (this.value === 'guaranteed') {
    console.log('will always return true');
  }
}
componentDidUpdate() {
  this.value = ''; //cleanup
}

在上面的示例中，如果您使用“setState”，则无法保证该值将始终在“shouldComponentUpdate”中更新，但是否将其用于预期目的并不重要。状态更改保证已按render时间刷新，因此它应该只包含渲染阶段使用的信息，而不是对象的事务/内部数据。您可以像往常一样自由地继续使用对象属性。

于 2018-02-04T20:47:48.463 回答