React Component Remounting

Changing a component's identity can cause React to discard the existing instance and mount a new one. A remount resets that component's local state and reruns mount-time effects, unlike an ordinary re-render.

React reconciliation uses a component's position and identity in the rendered tree to determine whether an existing instance can be reused. When React can match the new element to the previous one, it generally preserves the component instance and its state.

A remount happens when React treats the new element as a different component instance. A common intentional mechanism is changing the element's `key`; when the key changes, React can remove the old instance and create a new one. This is different from merely changing props, which normally causes a re-render while preserving state.

During a remount, the old component is unmounted and its local state is discarded. Effects associated with the old instance are cleaned up, and the newly mounted instance starts with its initial state and runs its mount-time effects.

Remounting can be useful when a component should completely reset its internal state for a new identity, such as resetting a form when its record ID changes. It can also be accidental: an unstable or changing `key` can cause unnecessary teardown and recreation, losing user input and doing extra work.

Key points

• A remount creates a new component instance rather than updating the existing one.
• Changing a component's `key` can intentionally trigger a remount.
• Local state is reset when a component remounts.
• Unmount cleanup runs before the old instance is discarded.
• Use stable keys unless resetting component identity is intentional.

Interview questions

What is the difference between a re-render and a remount in React?

A re-render means React updates an existing component instance with new inputs or state. Its local state is normally preserved when React can match it to the previous tree. A remount means the previous instance is discarded and a new one is created. Consequently, the new instance starts with its initial state.

How can changing a `key` cause a component to remount?

React uses keys as part of element identity when reconciling children. If a component receives a different key, React can no longer treat that element as the same keyed instance. The old instance is removed and a new instance is mounted. This means its local state starts over.

What happens to state and effects when a component remounts?

The old component's local state is discarded because its instance no longer exists. Cleanup for its effects runs as part of unmounting. React then creates a new instance with initial state. Effects for that new instance can run according to their dependency behavior after mounting.

Give a practical case where intentionally remounting a component is useful.

One example is a form whose internal state should completely reset when the user switches to a different record. Giving the form a `key` based on the record ID can make each record a distinct component identity. When the ID changes, React mounts a fresh form with its initial values. This can be simpler than manually resetting every piece of local state.

Why can unstable keys cause difficult UI bugs?

Keys tell React which child corresponds to which existing instance. If keys change unpredictably, React may discard instances or associate state with a different logical item. That can reset input values, lose component-local state, and create unnecessary mounting work. Keys should therefore represent stable item identity rather than transient rendering details.