When to Use VirtualizedList
You should use VirtualizedList instead of FlatList when:- You need to work with immutable data structures
- You need custom data handling logic
- You need more control over item rendering and measurement
- FlatList’s API doesn’t meet your specific requirements
Example
Required Props
The data source. Can be any type - you define how to access it via
getItem and getItemCount.A generic accessor for extracting an item from any sort of data blob.
Determines how many items are in the data blob.
Takes an item from data and renders it into the list.
Common Props
Used to extract a unique key for a given item at the specified index. By default, looks for an
id or key property on the item.How many items to render in the initial batch. This should be enough to fill the screen but not much more.
Maximum number of items to render in each incremental render batch.
Determines the maximum number of items rendered outside of the visible area, in units of visible lengths. Higher values result in more memory consumption but fewer blank areas when scrolling quickly.
Amount of time between low-pri item render batches in milliseconds.
If true, renders items next to each other horizontally instead of stacked vertically.
Reverses the direction of scroll. Uses scale transforms of -1.
Rendered at the top of all the items.
Rendered at the bottom of all the items.
Rendered when the list is empty.
Rendered in between each item, but not at the top or bottom.
Called once when the scroll position gets within
onEndReachedThreshold of the rendered content.How far from the end (in units of visible length of the list) the bottom edge must be from the end of the content to trigger the
onEndReached callback.An optional optimization that lets you skip measurement of dynamic content if you know the size of items ahead of time.
Set this true while waiting for new data from a refresh.
If provided, a standard RefreshControl will be added for pull-to-refresh functionality.
This may improve scroll performance for large lists. Note: May have bugs (missing content) in some circumstances.
Configuration for determining when items are considered viewable.
Called when the viewability of rows changes.
Methods
scrollToEnd()
getItemLayout prop.
scrollToIndex()
getItemLayout.
scrollToItem()
scrollToIndex instead if possible.
scrollToOffset()
recordInteraction()
flashScrollIndicators()
Performance Optimization
getItemLayout
ProvidinggetItemLayout is crucial for:
- Using
scrollToIndexwith items outside the render window - Smooth scrolling without blank areas
- Better overall performance
windowSize
Controls how many screen lengths of content to render:- Smaller values = less memory, more blank areas
- Larger values = more memory, fewer blank areas
- Default of 21 means ~10 screen lengths in each direction
removeClippedSubviews
Enables native optimization to unmount components outside the viewport:- Can significantly improve performance
- May have rendering bugs on some platforms
- Test thoroughly before using in production
Important Caveats
- Internal state is not preserved when content scrolls out of the render window
- This is a
PureComponent- must pass changes via props - Content is rendered asynchronously offscreen
- By default, looks for a
keyoridprop on each item - More complex than FlatList - use FlatList when possible
Differences from FlatList
- Data Access: VirtualizedList uses
getItemandgetItemCountinstead of assuming an array - Flexibility: Works with any data structure, not just arrays
- Complexity: More props and configuration required
- Use Case: Designed for advanced scenarios where FlatList is insufficient