Keys in Practice: Beyond the Console Warning
Every React developer has seen it: the console warning about missing `key` props. It's tempting to "fix" it by just throwing in the array `index` and moving on. However, understanding why keys exist reveals one of React's most powerful optimization features: the **reconciliation algorithm**.
When a component's state or props update, React builds a new "tree" of elements and compares it to the previous one. This comparison is called "diffing". When React diffs a list of children, it uses the `key` prop to match children from the old tree with children in the new tree.
The `index` Anti-Pattern: A Case Study in Bugs
Let's see what happens when you use `index` as a key for a list that can be reordered or filtered.
Imagine a list of items where each item is a component that manages its own state (like a text input).
// ⚠️ ANTI-PATTERN: DO NOT DO THIS
const [items, setItems] = useState(['Apple', 'Banana']);
// ... user adds 'Cherry' to the *beginning* of the list ...
// Now items = ['Cherry', 'Apple', 'Banana']
return (
<ul>
{items.map((item, index) => (
<li key={index}>
{item} <input type="text" />
</li>
))}
</ul>
);- Before: React sees `key=0` ("Apple") and `key=1` ("Banana"). The user types "My note" into the input for "Apple".
- After: React sees `key=0` ("Cherry"), `key=1` ("Apple"), and `key=2` ("Banana").
- The Problem: React's diffing algorithm says: "The component with `key=0` used to be 'Apple', now it's 'Cherry'. I'll update it. The component with `key=1` used to be 'Banana', now it's 'Apple'. I'll update it."
- The Bug: The component instances (and their internal state) are recycled. The `input` with `key=0` (which still contains "My note") is reused for "Cherry". The `input` for "Apple" (now `key=1`) is recycled from the old "Banana" component, so it's empty. The user's state has been incorrectly associated with the wrong item.
Stable Keys: The Correct Solution
The solution is to use a key that is **stable** (doesn't change for a given item) and **unique** (no two items have the same key). This is almost always a unique ID from your data.
✔️ Good Practice
const data = [
{ id: 'a', name: 'Apple' },
{ id: 'b', name: 'Banana' }
];
{data.map(item => (
<li key={item.id}>
{item.name}
</li>
))}Keys are stable and unique. React can track items perfectly.
❌ Bad Practice
const data = ['Apple', 'Banana'];
{data.map((item, index) => (
<li key={index}>
{item.name}
</li>
))}Keys are unstable. Reordering or filtering will cause bugs.
What About `Math.random()`?
Using `key=0.712228927493072` is even worse than using `index`. Because the key will be different *every single time* the component renders, React will think the *entire list* was destroyed and recreated from scratch. This forces React to destroy all DOM nodes and component instances, leading to terrible performance and the loss of all state (like text in inputs or focus).
Key Takeaway: Always use a stable and unique ID from your data as the `key`. This is the single most important rule for rendering lists in React. It ensures high performance, predictable behavior, and bug-free state management in dynamic lists.
