react-doctor/no-did-update-set-state
Avoid calling this.setState in componentDidUpdate; derive the value with getDerivedStateFromProps to prevent re-render loops
- Category: State & Effects
- Severity: warn
- Source:
oxlint-plugin-react-doctor - Framework: global
- Enabled when: always
- Documentation: https://oxc.rs/docs/guide/usage/linter/rules/react/no-did-update-set-state
Validation prompt
Use this to decide whether a fired diagnostic is real or a false positive.
Fires on this.setState(...) reached directly inside a componentDidUpdate method of an ES5 (createReactClass) or ES6 (extends React.Component) component — including calls in if/ternary branches, since the method body counts as one function level. In the default allowed mode, calls nested more than one function deep are intentionally skipped, so setState inside setTimeout, Promise.then, or an event-handler callback does NOT fire; the strict disallow-in-func mode flags those too. False positive: a guarded setState wrapped in a prop-comparison if (prevProps.x !== this.props.x) is the React-sanctioned escape hatch and won't loop, even though the rule still flags it.
Fix prompt
Use this once validation confirms the diagnostic is real.
Move derived state out of the lifecycle: compute it in the static getDerivedStateFromProps(props, state) so no extra render is queued, e.g. static getDerivedStateFromProps(props) { return { name: props.name.toUpperCase() }; }. If you must keep setState in componentDidUpdate, gate it on a prop/state diff so it can't loop: if (prevProps.name !== this.props.name) this.setState(...). Prefer migrating the component to a function component with useEffect for side effects that depend on prior props. See https://oxc.rs/docs/guide/usage/linter/rules/react/no-did-update-set-state