javascript - 在这种情况下我需要使用 setState(function) 重载吗？

Question

想象一下这样的情况:

clickHandler(event) {
  var that = this;
  var cellIndex = event.target.id;

  if(that.inProcess) return;

  /* Temporarily clone state */
  var cloneState = JSON.parse(JSON.stringify(this.state));

  var currentCell = cloneState.gameCellArray[cellIndex];
  currentCell.shown = true;

  if (that.someCondition) {

          that.inProcess = true;
          setTimeout(function () {

              currentCell.shown = false;
              that.setState(cloneState);
              that.inProcess = false;

          }, 1000)

  }
  this.setState(cloneState);

}

现在我在理论上担心在我克隆状态的地方( clickHandler 中的第四个语句)可能会发生我没有得到状态的最新版本 - 因为有些 setState来自之前调用 clickHandler 的调用待定，这是有效的假设吗？

现在，我的问题是，如果我按照以下方式重写上面的代码(基本上使用 setState 和回调参数)，会更安全吗？ (就没有不同步状态而言)。

clickHandler(event) {
    var that = this;
    var cellIndex = event.target.id;
    if(that.inProcess) return;

    that.setState(function(prevState, props){

        var cloneState = JSON.parse(JSON.stringify(prevState));

        var currentCell = cloneState.gameCellArray[cellIndex];
        currentCell.shown = true;

        if (that.someCondition) {

                that.inProcess = true;
                setTimeout(function () {
                    currentCell.shown = false;
                    // Do I need to take some measures here also?
                    that.setState(cloneState);
                    that.inProcess = false;

                }, 1000)

        }
        return cloneState;

    })

}

我需要在 setTimeout 内部采取一些额外措施吗？还有(第二个重写版本)？

附: clickHandler只是改变状态的函数 - 假设当用户单击某些按钮时被调用。

pps。更一般地说，在我的第一个案例或第二个版本中，状态可能会出现什么问题(从同步的 Angular 来看)，详细的答案将不胜感激，以便更好地理解如何在 react 中管理状态。

Answer 1

这是一个很长的答案。如果您不想全部阅读，请向下滚动到底部的 TLDR。
请注意，我描述了一些可能在 React 17+ 中更改的实现细节。这就是为什么我们的文档更加模糊，以便大多数人不会过分依赖实现细节。但在这种情况下，您似乎对它的真正运作方式特别感兴趣，所以我必须比我想要的更具体。

Now I got worried in theory that where I clone state (third statement in clickHandler) it can happen that I don't get the most recent version of the state - since some setState calls from previous invocation of clickHandler are pending, is it valid assumption?

不。在此回复(React 16 和任何更早版本)时，事件处理程序中的 this.state 在您自己更新状态 之前读取 是安全的。所以这段代码很好:

handleClick() {
  var something = this.state.something;

它会给你当前的状态。
唯一的缺陷是，如果您自己调用 setState，您不应该期望 this.state 立即更新。所以这段代码不起作用:

handleClick(e) {
  this.setState({ something: e.target.value });
  var something = this.state.something; // Don't expect to get newValue here

Note: there is also another edge case pointed out in the comments: if you have several onClick handlers, the same pitfall applies: once you call setState() in a child event handler, you can’t rely on this.state being updated by the time the parent event handler runs. In fact it’s the reason this optimization is so useful: all setState() calls from a single browser event are batched, whether they happen in one or different components while the event bubbles.

尽管如此，这不是问题，因为 如果你调用 setState 你已经知道你将它设置为:

handleClick(e) {
  var newValue = e.target.value;
  this.setState({ something: newValue });
  // There's no need to "read" something from state.
  // Since you just set it, you already *know*
  // what you set it to. For example:
  doSomethingWith(newValue);

现在，有些情况下您想根据之前的状态 更新状态 。虽然您可以在事件处理程序中读取 this.state ，但这只能工作一次:

handleIncrement() {
  // This will increment once:
  this.setState({ counter: this.state.counter + 1 });
  // These won't work because this.state.counter isn't updated yet:
  this.setState({ counter: this.state.counter + 1 });
  this.setState({ counter: this.state.counter + 1 });

为了让你不必担心这样的情况， React 提供了一个不同的 setState() 重载，它接受一个函数 。该函数将在应用更新时接收当前状态，以便您可以安全地使用它。 React 将确保通过所有挂起的函数“线程化”当前状态:

function increment(prevState) {
  return { counter: prevState.counter + 1 };
}

// ...
handleIncrement() {
  // Each function in the queue will receive the right state:
  this.setState(increment);
  this.setState(increment);
  this.setState(increment);
  // So this will increment three times.

从 React 16 及更早版本开始，此重载仅在您从同一事件处理程序多次调用 setState() 时才有用。但是，由于它也适用于其他情况，因此我们通常建议在任何时候您的 setState() 调用取决于当前状态 时使用它，这样您根本不需要考虑这一点。但是，如果您的代码在没有它的情况下工作，并且尝试重写它使其更加困惑，那么现在不要打扰。
将来我们可能还会在更多情况下依赖它，但我们会在 future 的版本中明确指出任何此类更改。我们还将为此开发更“自然”的 API，因为我们注意到人们对矛盾感到困惑，因为 setState() 的明显命令性质，以及我们推荐的更实用的方法。

在您的特定情况下，我实际上认为第一种方法更简单。您只在事件处理程序中调用 setState() 一次(超时发生在以后)，因此多次连续调用的陷阱不适用。
你使用函数式 setState() 形式的第二种方法实际上没有正确使用它，使整个代码更加困惑。 setState() 的函数形式假定您传递给它的函数是 pure 。例如，这是一个纯函数:

function increment(prevState) {
  return { counter: prevState.counter + 1 };
}

但是，您传递的函数不仅会计算下一个状态，还会安排超时、保留一部分状态、在原地改变它，并在超时内再次调用 setState。这显然是 而不是 纯函数的行为方式。经验法则是 如果您不在 render() 内做某事，您也不应该在 setState() 更新程序函数 内做那件事。
同样，在 React 16 或更低版本中，在这种特殊情况下将代码重写为函数形式不会有好处(我解释了上面的原因:您只是调用了 setState() 一次，而您并没有尝试正确读取状态之后)。但是如果你确实想使用函数形式，你需要确保你传递的函数是纯函数。问题是:你把超时逻辑放在哪里？
我的观点是 超时逻辑最好放在 componentDidUpdate() 生命周期钩子(Hook) 中。这样，只要满足必要的条件，它就会真正由状态更改触发——无论它发生在组件的哪个位置。例如，即使您有两个按钮触发相同的状态更改，它们都会导致 componentDidUpdate() 触发，并且它可以根据状态更改的方式运行超时逻辑。
由于您的问题是关于基于 this GitHub discussion 实现内存游戏，因此我写了一些伪代码来说明我将如何处理此任务。让我在这里引用我的答案:

I think that if you split the timeout-related part of this logic into the componentDidUpdate lifecycle hook, the code could be easier to understand. There might also be a better way to model the state itself. The matching game seems like a “state machine” with a few different valid states (nothing selected, one item selected and waiting, two right items selected, two wrong items selected).

It might be worth encoding these possible game states more directly into your component state and think more carefully about how to represent them with objects. For example, it might be that instead of an array of cell values it is easier to think about an explicit state like:

{
  openedCells: [1, 2], // array of ids
  firstSelectedCell: 5, // could be null
  secondSelectedCell: 7, // could be null
}

and then implement conditional logic in componentDidUpdate, e.g.

handleClick(e) {
  // Are we waiting for a timeout? Reset it.
  if (this.resetTimeout) {
    clearTimeout(this.resetTimeout);
  }

  const id = ... // get it from target node, or bind event handler to ID in render()
  this.setState(prevState => {
    if (prevState.firstSelectedCell !== null && prevState.secondSelectedCell === null) {
      // There is just one selected cell. We clicked on the second one.
      return {
        secondSelectedCell: id
      };
    }
    // We are selecting the first cell
    // (either because we clicked to reset both or because none were selected).
    return {
      firstSelectedCell: id,
      secondSelectedCell: null
    };
}

componentDidUpdate(prevState) {
  if (prevState.secondSelectedCell !== this.state.secondSelectedCell) {
    // We just picked the second cell.
    if (isSamePicture(
      this.state.secondSelectedCell,
      this.state.firstSelectedCell
    ) {
      // Same picture! Keep them open.
      this.setState(prevState => {
         // Add them both to opened cells and reset.
         return {
           firstSelectedCell: null,
           secondSelectedCell: null,
           openedCells: [
             ...prevState.openedCells,
             prevState.firstSelectedCell,
             prevState.secondSelectedCell
           ]
         };
    } else {
      // Clear both in a second.
      this.resetTimeout = setTimeout(() => {
        this.setState({
          firstSelectedCell: null,
          secondSelectedCell: null,
        });
      }, 1000);
    }
}

Then, in the render method, you can show cells if either they are in openedCells or they are firstSelectedCell or secondSelectedCell.

我希望这有帮助!
总而言之， 这里是 TLDR :

至少在 React 16(或更早版本)中，在事件处理程序中的第一个 this.state 调用之前读取 setState() 将为您提供当前状态。但是不要指望它会在 setState() 之后立即更新。

setState() 的函数重载防止了这个陷阱，但它要求传递的函数是纯函数。设置超时并不纯粹。

componentDidUpdate() 生命周期钩子(Hook)可能是设置依赖于状态的超时更好的地方。