FlatList data, renderItem, and keyExtractor
core FlatList props.
data is the array, renderItem maps each item to a component, keyExtractor returns a stable unique key letting React reconcile and reuse rows.
What's really being asked
Whether you know FlatList's essential API and the role keys play in React's reconciliation, especially for a virtualized, frequently updated list.
The full answer
The data prop is the array of items to render. The renderItem prop is a function that receives an object containing the current item and its index and returns the element for that row. The keyExtractor prop returns a unique, stable string for each item, typically item.id. React uses these keys to identify which elements correspond across renders. With stable keys it can reuse existing rows, move them when order changes, and only re-render what actually changed, preserving each row's internal state. Without unique keys, or with index-based keys, React matches by position; when items are inserted, removed, filtered, or reordered, state and views attach to the wrong items, causing flicker, incorrect content, and unnecessary remounts.
The mistakes people make
Using the array index as the key on a list that can change order or length, which is the classic bug. Returning a non-unique value, leading to React warnings and reconciliation errors. Forgetting keyExtractor entirely when items lack a key property. Putting heavy computation in keyExtractor; it should be cheap and pure.
What usually comes next
What goes wrong concretely if you use index as a key in a deletable list? How does keyExtractor interact with item recycling in virtualization? What if your data items genuinely have no unique id?
A concrete example
A todo list renders with keyExtractor returning item.id. The user deletes the second of five todos. Because keys are stable ids, React removes exactly that row and the others keep their checkbox state. If keyExtractor had returned the index, React would treat the deletion as the last row vanishing and shift content up, so a checked box could appear on the wrong todo and an input could keep stale text.
Interview question
Why is using the array index as keyExtractor problematic for a list where items can be deleted or reordered?
- a.React matches elements by key, so shifting indices attach state and views to the wrong itemsCorrect
- b.Index keys disable virtualization for the list
- c.FlatList forbids numeric keys entirely
- d.Index keys are too long and slow down hashing
Why? this is the answer
Keys identify items across renders. When indices shift after a delete or reorder, React reconciles by position and binds row state to the wrong item. A stable id avoids this.
Just read this? Test yourself on what you have been reading.
Read the original → reactnative.dev
- #react-native
- #flatlist
- #keys
- #reconciliation
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react-native — each one lists the topics its interview covers.
See open roles