FlatList and list virtualization

WHAT THIS TESTS Whether you reach for the virtualized list component and can explain windowing, rather than mapping a large array inside a ScrollView.

A GOOD ANSWER COVERS For a long list you use FlatList, or SectionList when the data is grouped into sections. The core principle is virtualization, often called windowing: rather than mounting every row, FlatList renders only the items within the visible viewport plus a configurable buffer around it, and it unmounts or recycles items that scroll far out of view. This keeps the number of mounted views and the per-frame render cost roughly constant no matter how many thousands of items the data contains, so memory stays bounded and scrolling stays smooth. By contrast, a ScrollView containing a mapped array instantiates every child up front, which is fine for a handful of items but blows up memory and initial render time for large lists. You should mention supporting props that keep it smooth: a stable keyExtractor, getItemLayout when row height is fixed to skip measurement, and memoized renderItem components to avoid needless re-renders.

COMMON WRONG ANSWERS Using a ScrollView with map for a large dataset. Forgetting keyExtractor or using array index as the key, hurting recycling. Defining renderItem inline so it recreates every render. Ignoring getItemLayout for fixed-height rows. Assuming FlatList alone fixes all jank without memoizing item components.

LIKELY FOLLOW-UPS How do windowSize, initialNumToRender, and maxToRenderPerBatch tune virtualization, when would you choose FlashList, why is getItemLayout helpful, and what causes blank cells during fast scroll.

ONE CONCRETE EXAMPLE Rendering a 10,000-row contact list: a ScrollView would mount 10,000 rows on first render, freezing the app. A FlatList with data set to the contacts, a keyExtractor returning each contact's id, and a memoized renderItem mounts only the dozen or so rows on screen plus a small buffer; as you scroll, off-screen rows are recycled, so the app uses a small, constant amount of memory and scrolls at 60 frames per second.