Why does React need a key on list items, and what actually breaks if you use the array index?

Keys tell React which element in the new list corresponds to which one in the old list, so it can move, keep or remove DOM nodes and their state instead of matching purely by position. Array indexes only work for static lists. If items get reordered, inserted at the front or deleted, the index for a given item changes, React reuses the wrong node, and state such as input values lands on the wrong row.

A key is how React answers the question, is this the same item I saw last render. Without one it pairs children by position, so when a row moves React thinks the content changed and patches the existing node instead of moving it. With a stable key it knows the item moved, keeps its DOM node and its state, and reorders. The index trap is that an index describes the position, not the item. I hit this on a table where each row had a checkbox and a notes field. Delete row two and every row below shifts up one index, so React pairs the wrong nodes and you end up with someone else's notes sitting in your row. It looks like a data bug and it is a key bug. So I use whatever stable id comes with the data, usually the database id. If there genuinely is not one, I generate an id when the item is created rather than during render, because generating in render gives you a fresh key every pass and remounts the whole list.