React Native Interview Questions

ScrollView lays out and renders every child immediately — fine for small, fixed collections but memory-heavy for hundreds of rows. FlatList is built on VirtualizedList under the hood: it mounts only the window of items near the viewport and recycles off-screen rows, so memory usage stays roughly constant as the data set grows.

View is the core container primitive in React Native. Every layout — whether wrapping text, images, or other components — is composed of View nodes that map directly to native views, and React Native applies Flexbox rules (via Yoga) to position them.

React Native 0.73 introduced React Native DevTools, a first-party, built-in debugger that replaces the older Flipper-based workflow. It integrates directly with Metro and provides layout inspection, network inspection, console logs, and JavaScript debugging without requiring an external app.

ScrollView renders all 1,000 items at once, causing heavy memory and CPU usage on mount and scroll. FlatList virtualizes by mounting only the items in the visible window plus a configurable buffer, dramatically reducing work. FlashList (by Shopify) adds component recycling on top of virtualization, reusing mounted component instances rather than creating and destroying them, which yields even smoother scrolling for large lists.

FlatList is the React Native core component purpose-built for long lists: it virtualizes its children via an underlying VirtualizedList, recycling rows that scroll off-screen so only items near the viewport are mounted. ScrollView, by contrast, renders every child at once, which causes memory and performance issues for large lists. SectionList builds on the same virtualization machinery but adds section headers — view recycling is not exclusive to it. VirtualizedList is the lower-level primitive FlatList wraps; it is not intended for direct use in typical app screens.

On the initial mount, both effects run in declaration order. The first effect (empty dependency array) calls setCount(0 + 1), scheduling a re-render, but the state update is not applied yet during this effect cycle. The second effect runs immediately after with count still equal to 0, printing 0. React then re-renders with count = 1. The first effect does not re-run (its deps array is empty and unchanged). The second effect's dependency [count] changed from [0] to [1], so it runs again and prints 1. No further state updates occur, so the output is 0 then 1.

React's reconciler splits work into a pure render phase (compute the diff) and a side-effect commit phase (apply to the host tree). useEffect callbacks are scheduled after the commit phase completes, so the screen has already been updated before they run — this is why reading or mutating native views inside useEffect is safe, but doing so during render is not.

Each correct option targets a distinct layer of the virtualization pipeline. (a) React.memo on the row prevents React from re-rendering every visible row when the parent re-renders — without it, a parent state change re-renders all 5,000 row instances that are currently mounted. (b) Lowering windowSize reduces the number of offscreen items FlatList keeps mounted on either side of the viewport, directly cutting memory usage and the render work that happens during scroll. (c) getItemLayout lets VirtualizedList compute an item's pixel offset and length arithmetically, eliminating the native layout-measurement pass for every item and enabling O(1) scrollToIndex. (e) A stable, unique keyExtractor lets React's reconciler match existing row instances across data changes; without it, items may unmount and remount unnecessarily, thrashing memory and causing jank. (d) is the opposite of an optimization: setting initialNumToRender to the full data length defeats virtualization by rendering all 5,000 rows synchronously on first paint, spiking memory and blocking the main thread.

getItemLayout is an opt-in contract that tells VirtualizedList the exact pixel position and height of every item so it can skip on-mount measurement and jump to any index in O(1). Here, styles.featuredRow (height: 120) overrides styles.row (height: 60) for every 50th item because React Native merges style arrays left-to-right, so featured rows are actually 120 px tall. Yet lines 20–21 hard-code a uniform length of 60 and compute offset as 60 * index, ignoring the extra 60 px contributed by each featured row. The cumulative offset drifts by 60 px for every featured row before the target, so scrollToIndex overshoots; the virtualization window also miscalculates which cells intersect the viewport, causing featured rows to pop in late. The fix is either to compute the real cumulative offset (summing actual heights) inside getItemLayout, or to remove getItemLayout entirely so VirtualizedList falls back to measuring each cell. removeClippedSubviews, windowSize, initialNumToRender, and maxToRenderPerBatch are all correctly configured and do not cause this symptom.