Class Component Lifecycles

Class component lifecycle methods let React notify a component about mounting, updates, unmounting, and certain errors. Use post-commit methods for external synchronization, clean up resources on unmount, and keep render free of side effects.

Class component lifecycles are methods React calls at defined points as a class component is created, updated, and removed. The main phases are mounting, updating, and unmounting; error handling also has dedicated lifecycle methods.

During mounting, React calls the constructor when one is defined, then render, and then componentDidMount after the component has been committed to the DOM. Use componentDidMount for work that needs a mounted component, such as starting a subscription or requesting data. Avoid putting side effects in render.

When props or state changes cause an update, render runs again. React then calls componentDidUpdate after the update is committed. Its previous-props and previous-state arguments let you detect meaningful changes before performing follow-up work; guard state updates there to avoid an update loop.

Before removing a component, React calls componentWillUnmount. Use it to release resources created by the component, such as timers, subscriptions, or event listeners. A component should not try to update its state as part of unmount cleanup.

Some older lifecycle methods, including componentWillMount and componentWillReceiveProps, are legacy APIs and are generally avoided in new code. Class components also have error-boundary methods: static getDerivedStateFromError can update state after a descendant throws, and componentDidCatch can report the error. Development Strict Mode may intentionally repeat certain lifecycle-related work to help expose unsafe side effects.

Key points

• Mounting typically includes render followed by componentDidMount after commit.
• componentDidUpdate runs after updates and provides previous props and state.
• componentWillUnmount is the place to release component-owned external resources.
• Keep render pure and guard state updates performed in componentDidUpdate.
• Legacy lifecycle methods should generally be avoided in new code.

Interview questions

When does componentDidMount run, and what work belongs there?

React calls componentDidMount after the initial render has been committed to the DOM. It is commonly used to start external work that requires a mounted component, such as a subscription or request. Resources started there should usually be released in componentWillUnmount. Rendering itself should remain pure.

How do you safely perform work in componentDidUpdate?

componentDidUpdate runs after an update has been committed, but not after the initial mount. Its arguments include the previous props and previous state, so the method can compare old and current values. If the comparison shows that work is needed, it may perform that work or update state. A condition is essential when calling setState there, otherwise the component can enter a repeated update cycle.

What is componentWillUnmount for?

componentWillUnmount runs immediately before React removes the component. Use it to undo ongoing work the component owns, such as clearing a timer, removing a listener, or unsubscribing. Cleanup should be paired with the corresponding setup so resources do not outlive the component. It is not a place to schedule a state update for the component being removed.

Why can setState inside componentDidUpdate be dangerous?

Calling setState in componentDidUpdate can cause another render and another componentDidUpdate call. That is sometimes needed, but it must be gated by a comparison with previous props or state so the follow-up update eventually stops. Prefer deriving values during render when no separate state transition is required. Unconditional setState in this lifecycle can create an infinite update loop.

Which lifecycle methods support class error boundaries, and what are their roles?

Mounting, updating, and unmounting methods describe a class component's progression through its lifetime. Error-boundary methods handle errors thrown by descendant components: static getDerivedStateFromError can choose fallback state, while componentDidCatch can record or report the error. These methods do not make a boundary catch every possible error, such as errors from event handlers. Use error boundaries around UI regions where a fallback is useful.