To the future commenters. I understand seeing a new warning is frustrating. But it points out legitimate issues that are likely causing bugs in your code. We would very much appreciate if you could refrain from expressing sarcasm and annoyance.

If you can’t understand where it’s coming from in the stack traces, please post screenshots or create reproducing sandboxes and we’ll try to help. Most of these are probably coming from a few libraries, so the most productive thing to do is to reduce these cases and then file issues with those libraries.

Thank you all.

We fixed the cases where the warning was over-firing in 16.13.1. The remaining cases are legit and need to be fixed.

I wish we had added this warning earlier. I’m sorry we didn’t. It was an oversight with the introduction of Hooks. I believe this must be caused by newer code that uses Hooks, because there was already the same warning for classes much earlier so any earlier code would’ve already seen this warning.

Note that this will likely start hard failing in future versions of React. Intentional or otherwise (we’ve had a lot of bugs with this pattern). So regardless, you might end up getting stuck on an old version. If it’s not possible to fix it, I’d recommend pinning to an older version of React.

However, that said, we want to help you and make it as easy as possible to fix these, including seeing if we can get help from library authors to publish fixed versions.

If you expand the little > arrow in the Chrome console you should also see an additional Stack trace (in addition to the Component stack in your screen shot). Can you post that too? That should show you the exact callsite that is causing a side-effect in render.

I think it is imperative that this error message be modified to include exactly which line of code is causing the error. It’s almost impossible to pinpoint whether it is local code or library code that’s causing the issue. External librairies libraries like react-redux and react-router are most likely the culprit may very well be the culprits yet it is impossible to easily determine that.

@sebmarkbage thank you for the response. The stacktrace appearing after clicking > is ridiculous. It contains 200+ items!

I was going to paste it there or give a link to pastebin but tried a different direction. I walked thru Github issues of some of used libraries and found out that one of suspects is redux-form: https://github.com/redux-form/redux-form/issues/4619. I hope that’s the only library which causes the errors and I’m going to wait for a fix before upgrading React.

But still, I’d ask to not close the this issue and I propose other developers to mention here libraries which also cause these errors.

@l0gicgate

I think it is imperative that this error message be modified to include exactly which line of code is causing the error.

There are limits to what we can do in JavaScript. But all the information is in the stack you see in the browser. All you need to do is to skip the lines that are inside React.

To see the JavaScript stack, you need to click on a small arrow next to the error message.

For example, look at this screenshot from earlier:

I appreciate it’s a bit annoying to dig through the stack, but it shouldn’t be that hard to skip the first several frames. The very next frame is the source of the problem. In this case, it seems like something inside the Formik library. So you can file an issue with it.

Small update on this thread

We’re going to release a patch of React soon that fixes over-firing of this warning for classes. So if you experience this, consider waiting a few days and then trying 16.13.1 when it’s out.

If you want to keep looking for the causes, I hope https://github.com/facebook/react/issues/18178#issuecomment-595846312 explains how.

I see, so I take away from this that UNSAFE_componentWillReceiveProps is counted as rendering but componentDidUpdate isn’t.

@LabhanshAgrawal That’s correct. Some background explanation here:

Conceptually, React does work in two phases:

• The render phase determines what changes need to be made to e.g. the DOM. During this phase, React calls render and then compares the result to the previous render.
• The commit phase is when React applies any changes. (In the case of React DOM, this is when React inserts, updates, and removes DOM nodes.) React also calls lifecycles like componentDidMount and componentDidUpdate during this phase.

The commit phase is usually very fast, but rendering can be slow. For this reason, the upcoming concurrent mode (which is not enabled by default yet) breaks the rendering work into pieces, pausing and resuming the work to avoid blocking the browser. This means that React may invoke render phase lifecycles more than once before committing, or it may invoke them without committing at all (because of an error or a higher priority interruption).

Render phase lifecycles include the following class component methods:

• constructor
• componentWillMount (or UNSAFE_componentWillMount)
• componentWillReceiveProps (or UNSAFE_componentWillReceiveProps)
• componentWillUpdate (or UNSAFE_componentWillUpdate)
• getDerivedStateFromProps
• shouldComponentUpdate
• render
• setState updater functions (the first argument)

Because the above methods might be called more than once, it’s important that they do not contain side-effects. Ignoring this rule can lead to a variety of problems, including memory leaks and invalid application state. Unfortunately, it can be difficult to detect these problems as they can often be non-deterministic.

I’m new to react but I had code like this:

import React, { useState } from "react";

function Home() {
  const [mobileNavOpen, setMobileNavOpen] = useState(false);
  return (
    <div>
      <button
        onClick={(): void => setMobileNavOpen(true)}
        type="button"
        className="btn"
      >
        X
      </button>
      {mobileNavOpen && <MobileNav setMobileNavOpen={setMobileNavOpen}/>}
    </div>
  );
}

function MobileNav() {
  return (
    <div>
      <button
        onClick={setMobileNavOpen(false)} //problem here
        type="button"
        className="btn"
      >
        X
      </button>
    </div>
  );
}

export default Home;

Which resulted in: Cannot update a component from inside the function body of a different component.

All I had to do is add an arrow function to setMobileNavOpen in MobileNav like so:

import React, { useState } from "react";

function Home() {
  const [mobileNavOpen, setMobileNavOpen] = useState(false);
  return (
    <div>
      <button
        onClick={(): void => setMobileNavOpen(true)}
        type="button"
        className="btn"
      >
        X
      </button>
      {mobileNavOpen && <MobileNav setMobileNavOpen={setMobileNavOpen}/>}
    </div>
  );
}

function MobileNav() {
  return (
    <div>
      <button
        onClick={(): void => setMobileNavOpen(false)} //fixes problem
        type="button"
        className="btn"
      >
        X
      </button>
    </div>
  );
}

export default Home;

And that fixes the problem, hope this helps someone!

Your example is actually one of the early mistakes people make with react. I’m not sure it’s exactly the same issue that’s being discussed here. Your line here: onClick={setMobileNavOpen(false) is calling the function during the button tender, not on click. That’s why wrapping it in a arrow function fixes it.

This is starting to crop up more and more in third party libraries now: urql, Apollo.

I ran into this and for several hours I assumed the problem was in my code. The condensed stacktrace points at my components, and it’s not unusual for me to see third party libraries in the expanded stacktrace when I did explicitly trigger an error. From my (albeit limited) research into this particular warning, it seems that most developers are not causing this issue themselves, but rather depending on code that does. Usually it’s good practice to assume it isn’t a bug upstream but when it is an upstream bug, wasting time tracking down a problem in your code that doesn’t exist is rather frustrating. Is there anything React can do to help an average user determine if it was code they wrote, or code they depend upon that caused the issue?

One thing I note from the Apollo issue is:

The warning’s stacktrace is showing the component that initialed the changes, not the one that gets re-renderd [sic] by those changes

If this is correct, can React give more information here? Perhaps telling us both the initiating component and the components that it caused to be updated?

I ran into this recently and the fix was wrapping setState handler call sites in useEffect, like so: https://github.com/airbnb/lunar/commit/db08613d46ea21089ead3e7b5cfff995f15c69a7#diff-1c3bdd397b1ce5064142488877045306R56 (onChange and onSubmit use setState higher up the chain).

@martinezwilmer Where is onPriceUpdated being called? Maybe try wrapping it in useEffect?

@LabhanshAgrawal In your stack, UNSAFE_componentWillReceiveProps calls some fitResize which dispatches a Redux action, which in turn updates a bunch of components. Hence the problem. So yeah, changing that to componentDidUpdate works.

@suhanw In your stack, something called ModuleImpressionTracker appears to dispatch a Redux action during a constructor. Constructors shouldn’t have side effects. I think that’s the cause of the issue, not your Hook.

As I said upthread, I would be very surprised if whatever’s happening here is an issue with React-Redux.

That said, I’m also not even sure exactly what triggers this message in the first place. I half-get what the error message is saying, but what kind of app code pattern would actually be an example of that behavior?

@gaearon just upgraded and the error disappeared! Thank you guys for your work!

Calling setState of your own component during render is a supported pattern (although it should be used sparingly). It’s setState on other components that are bad. You can’t detect those statically.

@MeLlamoPablo

I have one question: is the order of the very first render guaranteed? Because that’s all we need to funcion properly (once we know the order of the breadcrumbs, we don’t care about the order of the subsequent renders).

Not strongly. I think it mostly happens to work in the current version of React, but that may well change in the future. Even today, combined with features like lazy and Suspense it is not guaranteed.

How would React know that a parent component has any children otherwise?

Sibling order is not guaranteed. For parent/child order, you’re right parents have to render first; however, React may need to re-render the parent again before it gets to a child, or even after it has rendered the first child but before the second one. Again, once you add features like code splitting, you lose guarantees even faster.

This is fragile.

Yeah, this is one of the cases I referred to in https://github.com/facebook/react/issues/18178#issuecomment-600369392. We’ll mute the warning in this case. The warning itself is legit and as you rightly say, conceptually it’s a problem in classes too. However, the discrepancy doesn’t make sense so we’ll mute it for both cases for now when it’s coming from a class (which it is, in this example).

@gaearon I wanted to create a codesandbox but the latest version of the library has some issues with it. Error is not thrown in the old versions. At the moment it seems that the only way to reproduce it is to spin it up in Create React App locally 😦

OK so looking deeper into this, I think we’re warning in more cases (e.g. for classes) than we originally intended. We’ll look into silencing some of those.

I guess even if it’s more than intended, in my opinion it’s a good thing to have as it helps in improving our projects using classes.

@Glinkis Yeah maybe let’s wrap it up here but my suggestion would be to read useRouteMatch in the parent component, pass the ID as a prop, and then read props in selector like you normally would. (I don’t actually know how this is done in Redux these days but there must be some way.)

OK so looking deeper into this, I think we’re warning in more cases (e.g. for classes) than we originally intended. We’ll look into silencing some of those.

We were facing this issue in Hyper but we are not using hooks, and couldn’t find anything in the render call from the call stack. But there was a call in UNSAFE_componentWillReceiveProps in the stack. Updating that with componentDidUpdate fixed the issue for us https://github.com/zeit/hyper/pull/4382 Posted it here if it might help someone

@samcooke98 I’ve opened a PR for this https://github.com/facebook/react/pull/18316

I’m new to react but I had code like this:

import React, { useState } from "react";

function Home() {
  const [mobileNavOpen, setMobileNavOpen] = useState(false);
  return (
    <div>
      <button
        onClick={(): void => setMobileNavOpen(true)}
        type="button"
        className="btn"
      >
        X
      </button>
      {mobileNavOpen && <MobileNav setMobileNavOpen={setMobileNavOpen}/>}
    </div>
  );
}

function MobileNav() {
  return (
    <div>
      <button
        onClick={setMobileNavOpen(false)} //problem here
        type="button"
        className="btn"
      >
        X
      </button>
    </div>
  );
}

export default Home;

Which resulted in: Cannot update a component from inside the function body of a different component.

All I had to do is add an arrow function to setMobileNavOpen in MobileNav like so:

import React, { useState } from "react";

function Home() {
  const [mobileNavOpen, setMobileNavOpen] = useState(false);
  return (
    <div>
      <button
        onClick={(): void => setMobileNavOpen(true)}
        type="button"
        className="btn"
      >
        X
      </button>
      {mobileNavOpen && <MobileNav setMobileNavOpen={setMobileNavOpen}/>}
    </div>
  );
}

function MobileNav() {
  return (
    <div>
      <button
        onClick={(): void => setMobileNavOpen(false)} //fixes problem
        type="button"
        className="btn"
      >
        X
      </button>
    </div>
  );
}

export default Home;

And that fixes the problem, hope this helps someone!

@sebmarkbage I can no longer reproduce this problem. We have update some libraries and the problems over.

Hard to find the precise line concerned by the warning here:

@gaearon do you again have one tip about it ?

I have the same problem and I’m seeing that the warning is showing the first time that i write in my redux field or when i clear all it

I face the same problem with Redux-form!