Think about identity rather than warnings
A key helps React relate a rendered child to its counterpart across changes in a collection. Removing a console warning is only the visible symptom. The real design question is which item should preserve its local state when the list changes. Choose a key that represents the record’s stable identity, rather than its current position or its appearance during one render.
Try an editable task example
Suppose three rows each contain a task name and an editable note. The visitor types a note in the second row, then the first row is removed. With position-based keys, the remaining positions may inherit state associated with a different task. Stable task identifiers keep the note attached to the intended record as the visible list becomes shorter.
Generate identifiers at creation time
New local records can receive an identifier when they are created, and imported records can use a reliable existing key. Do not generate a fresh random key while rendering. A changing key tells React that the child is a different identity, which can reset inputs, focus and other local behavior on every update. Identifiers should be part of the data lifecycle.
Keep uniqueness in the relevant collection
Sibling children need distinct keys within their rendered list. A key does not need to be globally unique across every list on the page, but collisions among siblings make identity ambiguous. If external records lack a single stable identifier, define a meaningful composite key and document its assumptions. A display label may not be unique or stable enough for that role.
Use resets deliberately
Sometimes a changing key is exactly the desired behavior, such as starting a fresh editor for a newly selected document. That should be an intentional reset boundary. Do not depend on accidental key changes to clear errors or refresh data. Also pass an identifier as an ordinary prop if the child needs to read it; the reconciliation key is not an ordinary component field.
Verify state across structural changes
Test inserting at the beginning, sorting, filtering, deleting and restoring an item. Type into a row before each action and watch both the text and keyboard focus afterward. Include duplicate labels to ensure identity does not depend on a human-readable name. A correct list keeps persistent state with the record and resets it only where the interaction explicitly calls for a new identity.
Further reading
Put the idea to work.
Explore free browser tools for images, text and developer workflows.