Drills Repository
24 Drills · All Belts · reconciliation-keys
Keys are scoped to parent
React only uses keys to distinguish siblings within the same parent during reconciliation, not to provide global uniqueness across the application. Their purpose is to help React correctly preserve or reset state when sibling ordering changes.
Index key causes misplaced state
React matches existing child components during reconciliation using their keys, and index-based keys tie state to a position rather than to a specific item. When items reorder, this causes state to appear attached to the wrong logical item, which stable item IDs prevent.
Resetting component state with key
React treats a key as part of a component's identity during reconciliation, and changing that key anywhere in the tree, not just in lists, causes React to unmount the old instance and mount a completely new one. This produces fresh state rather than preserving the previous instance.
Index key reorder bug
When list items are reordered, index-based keys cause React to associate state with a position rather than with the specific item that owns it. This makes state like input values or selection appear to jump to the wrong element.
Conditional rendering preserves state
React preserves a component's state when the same component type occupies the same position in the tree across renders, regardless of prop changes. Even when JSX branches look syntactically different, React only compares the resulting tree structure during reconciliation.
Different component type resets subtree
React reconciliation treats different component types occupying the same tree position as entirely distinct subtrees. Replacing <Counter /> with <p> destroys the counter's state, so rendering <Counter /> again afterward creates a brand-new instance with freshly initialized state.
Reconciliation and component types
React reconciliation uses component types and tree structure, as expressed through JSX, to decide whether to preserve or discard state between renders. JSX therefore communicates the component boundaries that directly determine this behavior.
DOM preservation across renders
During reconciliation, React compares the new render output with the previous one and preserves DOM nodes when they represent the same element in the same position. Since the input itself did not change, React leaves the existing DOM node intact, including its current value.
State tied to tree position
React associates state with a component's position in the render tree, not with the JSX object itself. Even if the same JSX variable is reused, rendering it in two different positions creates two separate component instances with isolated state. This is part of React's reconciliation model for preserving component identity.
Key forces state reset
Keys participate in React's identity matching during reconciliation. Giving different keys tells React these are different component instances even if they appear in the same tree position. React will therefore destroy one state tree and create another when switching players.
Form state preserved unexpectedly
React preserves component state as long as the same component type remains at the same tree position. Changing props alone does not recreate the component instance. Without a changing key or position change, the existing state---including the draft message---remains attached to the component.
Keys identify siblings
Keys help React identify which list item corresponds to which rendered component across rerenders, especially when items are inserted, removed, or reordered. Without stable keys, React falls back to comparing elements by position, which can misattribute state and DOM nodes when the list order changes.