React `componentDidMount`

`componentDidMount` runs after React mounts a class component, making it a place for setup that needs the mounted DOM or external systems. Pair that setup with cleanup and handle relevant later changes in `componentDidUpdate`.

`componentDidMount()` is a lifecycle method on a React class component. React invokes it after the component has been mounted into the DOM, so it is appropriate for work that requires a mounted component, such as starting a subscription, opening a connection, or measuring a DOM node.

It receives no arguments and should not return a cleanup function. Put teardown logic in `componentWillUnmount()`, which runs when React removes the component. Setup and cleanup should correspond so resources do not remain active after removal.

Mount-time setup is not always the whole lifecycle. If the relevant props or state can change, implement `componentDidUpdate(prevProps, prevState)` and compare prior values before restarting work. `componentDidUpdate` does not run for the initial render.

In development Strict Mode, React may perform a mount, cleanup, and another mount to expose incomplete cleanup. Code should remain correct under this sequence. For function components, an Effect is commonly used for analogous synchronization; use `useLayoutEffect` when work must happen before the browser paints.

Key points

• React invokes it after a class component mounts.
• Use it for setup that requires a mounted component, including subscriptions and DOM access.
• Pair setup with `componentWillUnmount` cleanup.
• Use `componentDidUpdate` to react to relevant changes after the initial mount.
• Strict Mode development behavior can expose incomplete cleanup.

Interview questions

What is `componentDidMount` used for?

React calls `componentDidMount` after the class component has mounted. It is commonly used to start external synchronization, such as a subscription or connection, or to work with a DOM node. Cleanup belongs in `componentWillUnmount`. If the setup depends on values that can change, update handling must also account for those changes.

How do you handle a subscription whose configuration can change after mount?

`componentDidMount` handles initial setup after mounting, while `componentDidUpdate` handles synchronization after later prop or state changes. The update method receives previous props and state, which should be compared with current values to decide whether work is needed. It is not called for the initial render. Both lifecycle methods may be paired with `componentWillUnmount` for cleanup.

A mounted component opens a connection based on a prop. How should it respond when that prop changes?

Start the resource in `componentDidMount`, then in `componentDidUpdate` compare the current configuration with the previous one. If it changed, stop the old resource and start the correctly configured one. In `componentWillUnmount`, stop whichever resource is active. This makes the component’s external resource track its current props or state rather than only its initial values.

Why not start a subscription in the constructor or `render`?

The constructor runs while React is creating the class instance, and render describes the UI; neither is the right place for subscriptions or other side effects. `componentDidMount` runs after mounting, when DOM-dependent setup can occur. Cleanup should be placed in `componentWillUnmount`. Keeping side effects out of construction and render also avoids work being performed for instances or renders that do not become the committed UI.

What should you know about `componentDidMount` under Strict Mode?

In development Strict Mode, React can run mount setup, immediately run unmount cleanup, and then mount again. This is intended to reveal setup that is not properly reversible. A connection or listener should therefore be removed reliably by cleanup, and setup should tolerate being repeated. Do not interpret the development sequence as a guarantee that production performs the same extra cycle.