Practical technology learning
React List Keys: Check Item Identity When Rows Are Inserted or Reordered
Stable identity matters when a list changes around a user’s edits. Build a tiny local task list with distinct IDs and row-level notes, then move the records while checking which note belongs to which task. The exercise uses invented task data and makes no assumptions about a production application.
Give each record an identity before rendering
Prepare three tasks with IDs such as task-a, task-b and task-c. Their labels can be short and their notes initially empty. Record the IDs in the data itself rather than creating them anew every time the interface renders.
Choose an ID generation approach suitable for the source of the records. A database ID or an ID assigned when a local item is created can work. The essential property for this exercise is that the same task keeps the same identity as its position changes.
Create an observable row state
Give each row a small editable note owned by that row component. Type a different invented word into every row. Write the expected mapping between task ID and note in a separate notebook before modifying the list.
A static list of labels may hide an identity mistake because every rerender still displays plausible text. An editable note makes it easier to see when state appears attached to a different record after a structural change.
Perform one list operation at a time
First insert a new task at the beginning. Check every existing task-to-note pair. Restore the initial fixture, then remove the middle task. In a third run reverse the displayed order. Keep the input fixture and observations for each operation.
An index identifies an array position, which can change when items are inserted or moved. Compare a deliberately position-keyed version in the disposable exercise with a data-ID-keyed version. Keep the component structure the same while changing that one choice.
Review the key contract
Keys must remain stable for the same item and be unique among the relevant siblings. Creating a random key during rendering defeats that stability. A deliberately different key can also reset state, so decide whether preservation or reset is intended.
React uses key as a reconciliation hint rather than passing it as an ordinary component prop. If a row needs to display or submit its task ID, pass that value separately. Do not rely on a missing key warning as the complete identity test.
Record the acceptance checks
- Inserting an item preserves notes for existing task IDs.
- Deleting one task does not transfer its note to another.
- Reordering preserves the expected ID-to-note mapping.
- Sibling keys are unique and remain stable.
- Any intentional state reset is explained.
Extend the exercise after the basic cases pass
Try sorting by label or filtering the visible tasks, and state what should happen when a row unmounts. Keep those questions separate from the initial insertion test. Mango Engineers’ React course includes lists, components and state foundations; discuss the current JavaScript entry level and practical learning scope with the team.