React 19: "Cannot update a component while rendering a different component"

Q: Is this the same as 'Too many re-renders'?

They're related but not identical. Both come from calling setState during render instead of in an effect or event handler. "Too many re-renders" happens when the update targets the same component that's rendering, creating a loop. This warning happens when it targets a{" "} different component, which doesn't necessarily loop but is equally unsafe.

Q: Does this happen with useReducer too?

Yes — dispatch from useReducer triggers the same warning if called during another component's render, for exactly the same reason. The fix is identical: move the dispatch into an effect or an event handler.

Unlike “Too many re-renders”, this warning doesn’t freeze your app — it just shows up in the console once, pointing at code that otherwise seems to work fine:

⛔ Warning

Cannot update a component (Parent) while rendering a different component (Child). To locate the bad setState() call inside Child, follow the stack trace as described in https://react.dev/link/setstate-in-render

It’s easy to dismiss because nothing visibly breaks. It should not be dismissed: it means a component is mutating another component’s state during render, which violates the same purity rule behind “Too many re-renders” — it just doesn’t happen to loop this time.

Why React forbids this

React’s render phase is meant to be a pure calculation: given props and state, produce a description of the UI, without side effects. Calling setState on another component while you’re still calculating your own output means React might have to throw away and redo work it already started for that other component — or worse, apply the update in an inconsistent order relative to other pending updates. React can’t guarantee correctness in that scenario, so it warns loudly instead of silently misbehaving.

Pattern #1: deriving state from props without an effect

The most common trigger — a child tries to keep its parent’s state “in sync” directly during its own render:

function Parent() {
  const [selectedId, setSelectedId] = useState(null);
  return <Child onFirstRender={setSelectedId} />;
}

function Child({ onFirstRender }) {
  // Called during Child's render, updating Parent's state — exactly what triggers the warning
  onFirstRender("child-1");
  return <div>Child</div>;
}

The fix is to move the update into an effect, which runs after render has committed, not during it:

function Child({ onFirstRender }) {
  useEffect(() => {
    onFirstRender("child-1");
  }, [onFirstRender]);

  return <div>Child</div>;
}

💡 Consiglio

If what you actually want is “compute some derived value from props,” you often don’t need useEffect or a callback into the parent at all — just compute the value directly in the render body (const doubled = props.value * 2) instead of storing it in state and syncing it. Reach for useEffect specifically when you need to synchronize with something outside React (a parent’s state, browser APIs, a subscription).

Pattern #2: a callback ref that updates state immediately

function Parent() {
  const [height, setHeight] = useState(0);

  return (
    <div ref={(node) => node && setHeight(node.offsetHeight)}>
      <Child />
    </div>
  );
}

Callback refs run during the commit phase, which is later than render — but if this specific ref fires while a different component is still in the middle of rendering (a common case with nested components and React’s rendering order), you get the same warning. The safer pattern is to store the node in a ref and measure it in an effect:

function Parent() {
  const [height, setHeight] = useState(0);
  const nodeRef = useRef(null);

  useEffect(() => {
    if (nodeRef.current) setHeight(nodeRef.current.offsetHeight);
  }, []);

  return (
    <div ref={nodeRef}>
      <Child />
    </div>
  );
}

Reading the stack trace React gives you

The warning names both components involved — the one whose state was updated (Parent in the message above) and the one that was mid-render when it happened (Child). Start by searching Child’s source for any setState call that isn’t inside an event handler or a useEffect callback — that’s very likely the line.

FAQ

❓ Is this the same as 'Too many re-renders'?

They’re related but not identical. Both come from calling setState during render instead of in an effect or event handler. “Too many re-renders” happens when the update targets the same component that’s rendering, creating a loop. This warning happens when it targets a different component, which doesn’t necessarily loop but is equally unsafe.

❓ Can I just ignore this warning if my app seems to work?

It’s risky to. The behavior it warns about is explicitly unsupported — it may work today and break silently after a React update, or only manifest as a subtle bug under Concurrent rendering, where render work can be paused, restarted, or run twice.

❓ Does this happen with useReducer too?

Yes — dispatch from useReducer triggers the same warning if called during another component’s render, for exactly the same reason. The fix is identical: move the dispatch into an effect or an event handler.

Conclusion

This warning is React protecting you from a real correctness problem, not a false alarm to silence. Both triggers — a child syncing state into its parent during render, and a callback ref firing at the wrong moment — share the same fix: move the update into a useEffect or an event handler, somewhere that genuinely runs after render instead of during it.

References