Bug: old JSX from previous rendering visible in strict mode about react

[gaearon]

It's not supported to setTimeout during rendering. Rendering is supposed to be pure and not have side effects. So from that point on, it doesn't make sense to try to reason about what the code is doing.

[gaearon]

To clarify, since this might come across as overly defensive. I think there is sometimes an assumption that once you break the rules, it's okay to think about what the code does, because it should still behave in some meaningful way. So I wanted to convey my perspective that I work on the React team, and I usually give up as soon as I see some rule being broken. It's like there was a random variable in the middle of your calculation. At this point all my assumptions about how React works go out of the window because they don't matter.

Yes, I can try to retrace it, and explain what exactly goes wrong here. It would take some amount of effort. I can try to to do this. But ultimately a bug report needs to contain code that does not break the rules. Code that breaks the rules is never expected to work in any particular way, it might just happen to (not) work.

[gaearon]

You're right this does look like a bug though.

[gaearon]

Here's a minimal repro:

import { useState } from "react";

let ran = false;

export default function ReproduceBug() {
  const [state, setState] = useState("a");
  maybeRun(setState);
  return <div>{state}</div>;
}

function maybeRun(setState) {
  if (!ran) {
    ran = true;
    setTimeout(() => {
      setState("b");
    }, 500);
  }
}

What seems to happen here is that setState from the first StrictMode render is not capable of scheduling the update for some reason. So calls to it are ignored. However, in order to call it at all, you have to be breaking the rules of React (like in this repro, we're doing a side effect during rendering). If we were following the rules of React and either calling setState from an event handler or from an effect (or even during rendering directly — no timeouts), then the code would work. Because event handlers and "effects" would see setState from the second StrictMode render (which actually gets used):

export default function ReproduceBug() {
  const [state, setState] = useState("a");
  maybeRun(setState);
  return <div onClick={() => setState("c")}>{state}</div>;
}

Note clicking the div "works" because it "sees" the setState from the second StrictMode render (which got committed). You can verify that the setState versions between two StrictMode renders are indeed different:

import { useState } from "react";

export default function ReproduceBug() {
  const [state, setState] = useState("a");
  maybeRun(setState);
  return <div>{state}</div>;
}

let _setState;
function maybeRun(setState) {
  if (_setState && _setState !== setState) {
    throw Error("wat");
  }
  _setState = setState;
  setTimeout(() => {
    setState("b");
  }, 500);
}

I'm not sure why (maybe this is a bug, maybe this is a known difference), but as long as you follow the rules of React, I think this should not be observable. Regardless, this does not seem to be happening with @next versions. Maybe this means this was a bug that got fixed, or maybe it's a change to internal behavior. Since it breaks the rules in the first place, I'd say it's in the realm of undefined behavior.

[gaearon]

I've bisected the behavior change to #25583. Seems like this was an intentional change done for a different reason, but with fixing this as a consequence. This test in particular seems like our case: https://github.com/facebook/react/pull/25583/files#diff-19df471970763c4790c2cc0811fd2726cc6a891b0e1d5dedbf6d0599240c127aR456-R482

So I think we can close this as fixed. But we don't strictly consider this a bugfix because the behavior for breaking the rules is kind of undefined.

[MartinGeisse]

I have to agree in the sense that I cannot reproduce this problem without breaking the rules. Any further discussion would be out of scope for a bug ticket. Thank you very much!