Cannot update a component while rendering a different component (React)
Filed under Next.js & React errors
A state setter — yours or a parent's — is being called while React is in the middle of rendering, usually because a component copies a prop into state or calls a parent callback in its render body instead of in an event handler or effect.
Fastest route
Give your AI this prompt
Copy it, replace the bracketed part with your error, and send it.
Preview the prompt
React is warning: "Cannot update a component ([Parent]) while rendering a different component ([Child])". It appears when I [describe the interaction]. Please: 1) find the state setter or parent callback that is being called during [Child]'s render — including any helper the render body calls — and show me the exact line, 2) if the code is copying a prop into state or syncing two values, remove the mirror: use the prop or a value derived from it directly, or reset the component with a key from the parent, 3) move any genuine side effect (notifying the parent, navigation, toasts) into the event handler that causes it, or into useEffect if there is no event, 4) if state genuinely must adjust when a prop changes, use React's documented pattern of setting the component's OWN state during its own render with a previous-value comparison. Constraints: do not suppress the warning, do not wrap the call in a timer or setTimeout to hide it, and do not move state into a global store just to dodge the rule. Make one change at a time and tell me the exact interaction to retest.
Fix it yourself
Follow the repair
- Read the warning fully. It names both parties: "Cannot update a component (Parent) while rendering a different component (Child)". That is a treasure map — the setter belongs to the first name; the offending call lives in the second. Start in the child, not in the parent whose state looks haunted.
- Find the call in the render path. Look through the child component's body for anything invoked directly while rendering: its own render calling a setter passed down as a prop, an
onChange/onSyncfired unconditionally or under a condition, or a helper function that the body calls which itself sets state. Remember the call may hide one function deep — the body calls a formatter, the formatter reports upward. - Delete prop-to-state syncing. If a state variable only ever mirrors a prop, the state is the bug. Remove it and use the prop directly, or compute the needed value from the prop during render. If the component keeps local edits of a prop-based value, store only the edit (or the edited copy) and treat the prop as the source — and if the real need is "start fresh when a different item is shown", pass a
keyfrom the parent (<Editor key={item.id} />), which resets state cleanly with no syncing at all. - Use the sanctioned same-component pattern if you must. There is one legal setState-during-render: adjusting a component's own state while it renders, guarded by comparing to the previous value stored in another state. React handles it by re-rendering immediately before committing. If your sync code is really "when the prop changes, reset my own counter", this pattern — or the
keyfrom step 3 — expresses it without touching another component. - Move real side effects out of render. Parent notifications belong in the event that caused the change (the click, the submit, the selection), or in a
useEffectwatching the value when no event exists. Navigation and toasts likewise. The test for any line in a render body: "would this still be correct if React ran this component twice, or threw the result away?" If not, it doesn't belong there. - Retest the exact interaction. This warning is path-dependent: it fires only on the renders where values differ, which is why it lurked. Repeat the precise sequence that produced it — the same clicks, the same navigation — and confirm the console stays quiet and the values stay current. A clean first page load proves nothing about this one.
Why this happensOptional explanation
React renders in a strict order: it calls your components to learn what the screen should look like, then commits that picture. A state update says "the picture needs to change" — fine when it comes from a click, a timer, or a finished fetch, but a problem when it arrives mid-drawing, aimed at a component React hasn't finished with. So React logs the warning and discards the awkward update, which is why the visible symptom is often a value that's one step behind, or a sync that works except when it doesn't.
The code that does this is almost always trying to keep two things in agreement. A child receives a prop and, wanting to "watch" it, calls the parent's onChange or setter right in its body when the values differ. Or a component copies a prop into its own state during render so it can edit it — the classic prop-to-state mirror. AI tools write both patterns fluently because they look tidy, and they appear to work until a particular interaction renders the components in the order that exposes the update. One important distinction: calling a component's OWN setter during its OWN render is a documented, supported pattern (React re-renders it immediately, before committing). The error is only about updating a different component than the one rendering.
- Parent callback in a child's body:
onSync(...)invoked during render instead of from a handler. - Prop-to-state mirroring: copying a prop into state so the two can be "kept in sync".
- Render-time side effects: navigation, toasts, or store writes triggered while drawing.
- Library glue: form or state libraries wired so a field reports upward during render.
Quick answers
I read that setting state during render is sometimes allowed. Which is it?
Updating the SAME component during its own render is a documented React pattern — React immediately re-renders it before committing, which is the sanctioned way to adjust state derived from props. The error is specifically about updating a DIFFERENT component — usually a parent — while a child renders.
But I need the prop in state so I can edit it. What then?
Props exist precisely so you don't have to. If the state never changes independently of the prop, delete the state and use the prop (or a value computed from it) directly. If part of it is edited locally, store only the edited difference, or reset the component with a key when the prop changes.
What usually triggers it after an AI adds a feature?
Almost always: calling the parent's callback or setter directly in the child's render body 'to keep things in sync'. It's usually intermittent because it only fires on the renders where the values differ — which is why it appeared after things had been 'working'.