Chapter 30: Preserving and Resetting State

Core Idea

React preserves a component's state for as long as that same component type renders at the same position in the tree across renders — change either the position or the type at that position, and React discards the old state and mounts fresh, regardless of what the JSX "looks like" it's doing.

Key Concepts

• State is tied to a tree position, not to the JSX call site in your code. Two <Counter /> calls in different JSX branches of an if/else are still "the same position" if they render into the same slot of the parent tree — so toggling between them preserves state rather than resetting it, which often surprises people who expect each JSX line to be independent.
• Same component, same position → state preserved across re-renders, even if props change — e.g. re-rendering with different prop values keeps the internal useState intact.
• Different component types at the same position → state reset. Swapping <Counter /> for <div> (or for a completely different component) at the same tree position destroys the old subtree and mounts a brand-new one from scratch, resetting all its state — because React's identity check is by component type, not by "this general area of the screen."
• Resetting state at the same position on purpose: two options — (1) render the component in genuinely different positions (e.g. two separate JSX slots for two players, rather than one slot swapping between them), or (2) give the component an explicit key — changing the key value forces React to treat it as a different element even though the type and position are unchanged, so it unmounts the old instance and mounts a new one.
• key as a state-reset lever generalizes the list key behavior from Ch 17 — any component, not just list items, can be forced to reset by changing its key, which is the standard trick for "restart this form/component from scratch" (e.g. a chat input keyed by the currently open conversation's id).

Code Examples

// Force a fresh Form instance (state reset) whenever the recipient changes
<Chat key={recipient.id} recipient={recipient} />

• What it demonstrates: using key deliberately to reset a component's internal state when the logical "identity" of what it represents changes, even though its position in the tree stays the same.

Key Takeaways

1. React's state-preservation rule is (component type, position in tree) — not "this looks like the same UI to me."
2. Deleting a component from the tree deletes its state permanently — re-adding it later (even the "same" component again) creates a fresh instance with reset state.
3. Changing an element's key is the standard, intentional way to force a full remount/state-reset without restructuring your component tree.

Connects To

• Ch 17 (Rendering Lists): the original context where key was introduced, for list identity.
• Ch 29 (Sharing State Between Components): what "same position" means when state has been lifted to a parent.
• Ch 11 (Your First Component): why never nesting component definitions matters — it would create a new type identity on every render, permanently resetting state.