Sample questions
Rn Performance RenderingDifficulty 1
Why is FlatList generally preferred over rendering a long array with ScrollView + .map() in React Native?
- aFlatList moves all rendering work to a native UI thread so JS is never involved.
- bFlatList renders every item eagerly but caches the screenshots for faster scrolling.
- cScrollView cannot render more than 50 items due to a hard framework limit.
- dFlatList virtualizes rendering, mounting only items near the viewport.✓
Explanation:FlatList is virtualized: it only mounts items near the visible viewport and recycles/unmounts off-screen ones, which keeps memory and initial render cost low for long lists, unlike ScrollView which mounts everything immediately.
Rn Performance RenderingDifficulty 1
What is the main purpose of the keyExtractor prop on FlatList?
- aIt sets the visual key/label shown above each list item.
- bA stable, unique identity per item for correct tracking.✓
- cIt defines which items are allowed to be swiped to delete.
- dIt encrypts the list data before sending it over the network.
Explanation:keyExtractor returns a stable unique string per item, which React uses to identify items across re-renders/reorders instead of relying on array index, avoiding incorrect state reuse and unnecessary remounts.
Rn Performance RenderingDifficulty 1
What benefit does providing getItemLayout to FlatList give when all rows have a fixed, known height?
- aIt disables virtualization so the whole list renders at once for a smoother look.
- bIt lets FlatList skip measuring items and jump directly to any scroll offset.✓
- cIt automatically adds pull-to-refresh support to the list.
- dIt forces every row to re-render on every scroll event for pixel-perfect alignment.
Explanation:getItemLayout gives FlatList the exact {length, offset, index} for each row upfront, so it can compute scroll positions without an async measurement pass — this makes scrollToIndex/scrollToOffset instant and reduces layout jank.
Rn Performance RenderingDifficulty 1
What does the initialNumToRender prop on FlatList control?
- aHow many items render synchronously in the first render pass.✓
- bThe number of network requests fired when the list mounts.
- cThe number of items kept in memory after they scroll off-screen.
- dThe total number of items that will ever be rendered during the list's lifetime.
Explanation:initialNumToRender sets how many rows are rendered on the first pass so the user sees content immediately; too high a value slows the initial mount, too low can show blank space briefly before subsequent batches render.
Rn Performance RenderingDifficulty 2
A FlatList renders rows via renderItem={({item}) => <Row item={item} selectedId={selectedId} />}. When selectedId changes elsewhere in the screen, none of the rows update to reflect the new selection, even though Row reads selectedId from props. What is the most likely reason and correct fix?
- a
selectedId isn't part of data, so pass it via extraData to force re-render.✓ - bFlatList caches renderItem output forever; the fix is to change every item's
key on selection change. - cThis is expected and cannot be fixed without switching to
SectionList. - d
renderItem must be declared with useEffect instead of a plain function for external props to be picked up.
Explanation:FlatList does a shallow comparison based on data (and its own props) to decide whether to re-render rows; external values referenced inside renderItem but not part of data must be passed through extraData so FlatList knows to re-render when they change.
Rn Performance RenderingDifficulty 2
What does wrapping a functional component with React.memo(Component) do?
- aIt prevents the component's children from ever re-rendering, regardless of their own props.
- bIt permanently caches the component's first render output for the lifetime of the app.
- cIt converts the functional component into a class component internally for performance.
- dIt skips re-rendering the component when its props are shallowly equal to before.✓
Explanation:React.memo wraps a component so React skips re-rendering it when its props are shallowly equal to the last render — it only affects that component (not its children directly), and a parent re-render can still cause re-render if a prop reference changed.