Optimizing FlatList with variable item heights
layout optimization for mixed heights.
implement getItemLayout to return each item's length and cumulative offset so FlatList skips measurement and scrollToIndex works precisely; precompute heights per item type.
What's really being asked
Whether you understand that FlatList performs best when it does not have to measure items at runtime, and how to provide layout for items whose heights vary but are computable.
The full answer
The key tool is getItemLayout, which returns the length, offset, and index for a given position. Normally it is trivial for fixed-height rows, but with mixed content like text bubbles and image bubbles you must compute each item's height from its type and content, then accumulate offsets. To keep getItemLayout fast, precompute a running array of offsets when data changes so each call is a constant-time lookup rather than summing every prior item. Providing accurate layout lets FlatList skip synchronous measurement, which cuts blank cells during fast scrolling and, critically, makes scrollToIndex land precisely because FlatList knows the exact pixel offset of the target. If some heights are genuinely unpredictable, handle onScrollToIndexFailed to recover gracefully.
The mistakes people make
Returning a single constant height for items that actually vary, which corrupts every offset after the first variable item and makes scrollToIndex jump to the wrong place. Recomputing the full offset sum inside getItemLayout on every call, making it O(n) per item and slow for long lists. Omitting getItemLayout and then complaining scrollToIndex is unreliable. Measuring with onLayout and storing heights but never feeding them back to getItemLayout.
What usually comes next
Why does scrollToIndex misbehave without getItemLayout for off-screen items? How do you handle onScrollToIndexFailed? When is FlashList's automatic sizing a better fit than manual getItemLayout?
A concrete example
In a chat list, text messages are 60px and image messages are 220px. When messages change you build an offsets array by scanning once and summing per-type heights. getItemLayout for index i returns length from the item's type, offset from offsets[i], and index i, all O(1). Now scrolling is smooth with few blanks, and scrollToIndex to the latest message jumps exactly to its true offset instead of an estimate, even though earlier items have different heights.
Interview question
For a chat list mixing 60px text and 220px image rows, what makes scrollToIndex land accurately and reduce blanks?
- a.Setting onEndReachedThreshold higher
- b.Disabling virtualization so all rows are measured at once
- c.Returning a constant average height from getItemLayout for all rows
- d.A getItemLayout that returns each row's true length and precomputed cumulative offsetCorrect
Why? this is the answer
Accurate per-item length and offset let FlatList position rows without measuring and jump scrollToIndex to the exact pixel. A constant average height misaligns offsets after the first differing row.
Just read this? Test yourself on what you have been reading.
Read the original → reactnative.dev
- #react-native
- #flatlist
- #getitemlayout
- #performance
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