What are Keys in Flutter and why are they critical?

What's really being asked

This question tests whether you understand Flutter's three-tree architecture and the difference between Widgets, Elements, and RenderObjects. Specifically, it probes your knowledge of how the framework reconciles the widget tree against the element tree during rebuilds, and why explicit identity through Keys is necessary when widget positions change but their underlying data does not. It also checks if you know the practical API requirement that ReorderableListView children must have Keys.

The full answer

A good answer hits four things in order. First, define a Key as an optional identifier that tells Flutter's element tree, this widget is the same logical entity as before, even if it moved. Second, explain the default reconciliation algorithm: without a Key, Flutter matches elements by runtime type and tree position, then updates the widget reference and calls didUpdateWidget. Third, explain why this breaks in reorderable lists: when a user drags an item from index 0 to index 2, the widget tree now has different data at index 0, but Flutter reuses the old Element and State at index 0 because the widget type is identical. Fourth, state the fix: assign a stable ValueKey based on your model ID so Flutter recognizes the widget moved and reparents the existing Element with its State intact.

The mistakes people make

The biggest red flag is saying Keys exist to improve performance. They do not make diffing faster; they make it correct by providing identity. Another red flag is confusing GlobalKey with LocalKey. A GlobalKey grants global access to a State object from anywhere in the app, while LocalKeys like ValueKey, ObjectKey, and UniqueKey only control local reconciliation. Candidates also err by suggesting index-based keys, which defeat the purpose because the index is exactly what changes during a reorder.

What usually comes next

An interviewer might ask when to use ObjectKey versus ValueKey, which tests whether you know that ValueKey uses operator equality while ObjectKey uses identity. They might ask about GlobalKey and when it is appropriate, such as accessing FormState or scrolling a ListView. They might also ask how to preserve scroll position or animation controllers during reordering, which leads to discussions about AutomaticKeepAliveClientMixin or using PageStorageKey.

A concrete example

Imagine a todo list built with ReorderableListView where each child is a CheckboxListTile with a TextField for the task description. The list contains three items: task A unchecked at index 0, task B checked at index 1, and task C unchecked at index 2. The developer omits Keys. The user drags task B to index 0. Because all tiles have the same runtime type, Flutter sees a CheckboxListTile at index 0 and reuses the original Element from index 0. The State object still thinks it belongs to task A, but the widget now displays task B's text. Worse, the checkbox remains unchecked because the State from index 0 had isChecked false, while the checked State traveled with the Element that is now at index 1. The UI shows task B with an unchecked box and task A with a checked box. Adding ValueKey(todo.id) forces Flutter to match Elements by identity, so the checked State stays with task B's widget no matter where it moves.