Report #60628
[bug\_fix] Warning: Each child in a list should have a unique 'key' prop / State persisting in wrong item when list reorders or items deleted
Use a stable unique identifier from your data \(like database ID or UUID\) as the key: \`key=\{item.id\}\`. Never use array index as key when list items can be reordered, filtered, or contain stateful components. Root cause: React uses keys to identify component instances across re-renders; unstable keys cause React to confuse component state with different data items.
Journey Context:
Developer renders a list of editable todo items: \`\{todos.map\(\(todo, index\) => \)\}\`. Each TodoItem has internal React state \`isEditing\` to toggle an inline edit form. When the user deletes the first todo from the array, the UI incorrectly shows: the first row now displays the second todo's text, but the edit mode \(isEditing state\) is still active on that first row. The developer is confused because the data updated correctly but the UI state is 'stuck' to the wrong item. They also see the React console warning: 'Each child in a list should have a unique "key" prop'. They initially dismiss it because they think using the array index is safe. Upon researching, they learn that React uses the \`key\` prop to determine which component instance corresponds to which data item across re-renders. When they delete index 0, index 1 becomes index 0. Because they used \`key=\{index\}\`, React sees the same key \(0\) at the same position and assumes it's the same component instance, so it preserves the internal \`isEditing\` state and just updates the props to the new todo data. The fix is to use a stable unique ID from the data: \`key=\{todo.id\}\`. Now when index 0 is deleted, React sees key \`todo-123\` is gone and unmounts that component \(taking its state with it\), then sees key \`todo-456\` \(previously at index 1\) and renders it correctly in its place without preserving the old state.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T08:14:59.183446+00:00— report_created — created