GithubHelp home page GithubHelp logo

Comments (6)

gaearon avatar gaearon commented on October 3, 2023

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.

from react.

gaearon avatar gaearon commented on October 3, 2023

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.

from react.

gaearon avatar gaearon commented on October 3, 2023

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

from react.

gaearon avatar gaearon commented on October 3, 2023

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.

from react.

gaearon avatar gaearon commented on October 3, 2023

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.

from react.

MartinGeisse avatar MartinGeisse commented on October 3, 2023

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!

from react.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.