React `componentDidUpdate`

`componentDidUpdate` runs after a class component commits an update, but not after its initial render. Compare current props or state with the previous values before triggering side effects, and guard state updates to avoid loops.

In a React class component, `componentDidUpdate` runs after React has rendered and committed an update caused by changed props or state. It does not run after the initial render. React passes the previous props and previous state, so the method can compare them with `this.props` and `this.state`.

Use it for work that needs to happen in response to an update, such as synchronizing an external connection, making a request when a relevant identifier changes, or updating the DOM. Put such work behind a comparison so unrelated updates do not repeat it.

Calling `setState` here can cause another render and another call to `componentDidUpdate`. Only do so when necessary, and ensure the condition becomes false after the state change; otherwise, the component can enter an update loop.

If the class defines `getSnapshotBeforeUpdate`, its return value is passed as the third argument, `snapshot`. This supports reading information before the DOM update and using it afterward. For many function-component use cases, effects provide a related approach; class components remain supported, though React recommends functions for new components.

Key points

Interview questions

What is `componentDidUpdate`, and when does React call it?

`componentDidUpdate` is a class-component lifecycle method that runs after an update has been rendered and committed. It receives the previous props and state, which lets the component detect which inputs changed. It does not run for the initial render. A common use is to synchronize with an external system only when a relevant value changes.

How would you fetch data when a particular prop changes without fetching on every update?

Compare the current value, such as `this.props.userId`, with `prevProps.userId`. Start the request only when they differ, so unrelated component updates do not trigger it. If the request can become stale when the identifier changes quickly or the component unmounts, handle cancellation or ignore outdated results as appropriate. Initial loading belongs in `componentDidMount` or another suitable data-loading mechanism because `componentDidUpdate` does not run on mount.

What can go wrong if you call `setState` inside `componentDidUpdate`?

A `setState` call in `componentDidUpdate` can schedule another render, which can call the lifecycle method again. Guard the update by comparing current values with the previous values or by checking a condition that becomes false once the desired state is reached. Without a terminating condition, the component can repeatedly update itself. Even with a guard, avoid extra state when the value can be derived during rendering.

How do `getSnapshotBeforeUpdate` and `componentDidUpdate` work together?

`getSnapshotBeforeUpdate` runs before React applies the DOM update, and its return value is passed to `componentDidUpdate` as `snapshot`. This lets code preserve information about the old DOM, such as a scroll position, and use it after the update. `componentDidUpdate` itself runs after the DOM update has been committed, so it is too late to inspect the pre-update DOM state in the same way. The snapshot method should return a value or `null`.