Lists and Scrolling

ScrollView renders all of its children immediately, whether or not they are currently visible, and then scrolls the resulting content — exactly like a plain, overflow-scrolling View would. That makes it the right choice for content that is short and bounded (a settings screen, a form, a details screen’s body) and the wrong choice for anything unbounded, because memory and initial render time both grow linearly with the number of children, with no upper bound:

A few ScrollView props matter enough to call out by name:

FlatList is the default choice for anything that is a list rather than a fixed page of content — Places's own list of places, potentially hundreds or thousands of rows. Instead of mounting every row, it virtualizes: only the rows near the current viewport are actually mounted as native views at any given time, with rows that scroll far enough away being unmounted (or recycled) and re-mounted again if scrolled back into range. Three props are mandatory, not optional:

Beyond the three mandatory props, a handful round out most real screens:

As the figure shows, only a window of items around the visible viewport is ever mounted as real native views; everything outside that window exists solely as data, not as a rendered row — this is the mechanism the performance-tuning props below (windowSize, initialNumToRender, maxToRenderPerBatch) all control directly.

SectionList is FlatList’s sibling for data that is naturally grouped into sections, each with its own header — Places grouped by category or by visit month, for example. It replaces the flat `data array with a sections array of { title, data } groups, and adds renderSectionHeader:

stickySectionHeadersEnabled (the default on iOS, opt-in on Android) pins the current section’s header to the top of the viewport while its rows scroll underneath, the same behavior an iOS Contacts-style grouped list has natively.

VirtualizedList is the lower-level component FlatList and SectionList are both thin wrappers over — it implements the actual windowing algorithm (deciding which items fall inside the rendered window, mounting and unmounting rows as the viewport moves) against a more general data interface (getItem, getItemCount) rather than a plain array. Reaching for VirtualizedList directly is rare in application code — it exists mainly so a data structure that is not a plain JavaScript array (a linked list, a paginated store with its own indexing) can still be virtualized without first being copied into one — and every prop covered above for FlatList (aside from the array-shaped data itself) is really a VirtualizedList prop inherited through that wrapper.

Sorting or filtering an array on every render — including renders triggered by something unrelated, like a sibling component’s state changing — recomputes work that did not need to change. useMemo recomputes only when its dependencies actually change:

[…​places].sort(…​) copies the array before sorting — Array.prototype.sort mutates in place, and mutating a prop or a query’s cached data directly is exactly the kind of bug that only shows up later, once something else reads that same reference and finds it silently reordered.

A search box that filters a large list on every keystroke can make typing itself feel laggy, because each keystroke’s state update and the (possibly expensive) filter it triggers are treated as equally urgent by React. useDeferredValue splits them apart: the input’s own value updates immediately, while a deferred copy of that value — which the filtering useMemo depends on instead of the raw value — is allowed to lag a render or two behind under load, so React can keep the input responsive and catch the filtered list up shortly after:

isStale (query !== deferredQuery) is optional but useful — it is true for the brief window where the input already shows the new characters but filteredPlaces still reflects the previous query, a common signal for dimming the list slightly until the deferred value catches up.

onEndReached fires once the user has scrolled within onEndReachedThreshold (a fraction of the viewport’s length, e.g. 0.5 for "half a screen from the end") of the list’s end — the standard way to fetch the next page of an unbounded data set without a dedicated "Load more" button:

Guarding with hasNextPage/isFetchingNextPage matters because onEndReached can fire more than once while the user keeps scrolling near the end — without the guard, the same page gets requested multiple times in flight.

RefreshControl wraps FlatList’s native pull-to-refresh gesture — the spinner that appears when the user pulls the list down past its top — and is handed to `FlatList (or ScrollView) through the refreshControl prop rather than as a child:

refreshing controls whether the spinner is currently shown (driven by the query’s own in-flight state, not a separately tracked boolean) and onRefresh is called once when the gesture completes; the two are deliberately decoupled, so a manual refetch() call from somewhere else in the app still shows the same spinner correctly.

onViewableItemsChanged is called whenever the set of rows considered "visible" changes, according to viewabilityConfig — the mechanism behind marking a place as "seen" for analytics, lazily loading a row’s photo only once it is actually on screen, or auto-playing a video only in the row currently centered in the viewport:

Both viewabilityConfig and onViewableItemsChanged must keep a stable identity across renders — FlatList warns (and can behave incorrectly) if either changes on every render, which is why onViewableItemsChanged above is wrapped in useRef rather than declared as a plain inline function.

Four FlatList props tune the virtualization window the earlier figure illustrates, trading memory for scroll smoothness in either direction:

The other half of keeping a long list smooth is making sure renderItem does not force every row to re-render on every parent update. Wrapping the row component in React.memo — reusing, not redefining, PlaceCard's established shape — combined with a renderItem and keyExtractor that keep a stable identity across renders (useCallback, as in Places's own screen below) is what lets that memoization actually take effect:

Without a stable renderItem identity, a new function is created on every render of the parent screen, which defeats React.memo on the row entirely — FlatList sees a "new" renderItem reference and treats every row as possibly changed.

Shopify’s FlashList targets the exact same problem as FlatList — rendering a long list efficiently — with a different recycling strategy (reusing existing native view instances for new rows scrolling into view, rather than mounting and unmounting), which in practice yields noticeably smoother scrolling and lower memory use on long or complex lists, especially with variable row heights. It is close enough to a drop-in replacement that most of the props already covered above (data, renderItem, keyExtractor, onEndReached, refreshControl, onViewableItemsChanged) carry over unchanged:

The one prop FlashList adds that FlatList has no equivalent for is estimatedItemSize — a rough average row height in points, used to pre-size the recycling pool before any row has actually been measured; getting it roughly right (rather than exactly right) is enough to get most of FlashList’s performance benefit, and newer FlashList versions can estimate it automatically when it is omitted. For most new lists in a React Native app, including Places's own list below, FlashList is a reasonable default to reach for directly rather than a later optimization step — FlatList remains covered in full above because it is still the built-in, dependency-free choice, and because understanding its virtualization model is what makes FlashList’s own behavior legible.