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.

React Native components are styled via the style prop, which takes a plain JavaScript object of style key-value pairs (commonly created with StyleSheet.create) or an array of such objects. Unlike web React, there are no CSS class names or Tailwind classes built in, and className alone does not apply styles in core React Native.

In React Navigation's Stack navigator, navigate('Details') first searches the existing stack for a screen named Details; if found, it pops or jumps to that instance instead of creating a duplicate. If no such screen exists, it pushes one. push('Details') always pushes a brand-new instance onto the stack regardless of whether a Details screen is already there. This matters for scenarios like viewing the same detail page repeatedly without deduplication.

getItemLayout provides the exact pixel offset and length of every item without the FlatList needing to render and measure each one. This is mandatory for scrollToIndex because the list must compute the scroll position mathematically; without it, the runtime cannot know where item 5000 lives and throws the documented error. As a bonus, the list skips on-mount layout measurement of off-screen cells, improving scroll performance for large fixed-height lists.

On Android, a native module must extend ReactContextBaseJavaModule, annotate callable methods with @ReactMethod, and be registered through a ReactPackage whose createNativeModules() returns an instance of the module. By default, @ReactMethod (with isBlockingSynchronousMethod = false, the default) dispatches the method on the native modules background thread — not the UI thread and not the JS thread. Option (b) is wrong because isBlockingSynchronousMethod = true forces execution on the JS thread synchronously, which is the opposite of background. Option (c) is wrong because @UiThread forces the method onto the UI thread, not a background thread. Option (d) is wrong because @ReactMethod alone does not auto-register the module — a ReactPackage is required — and isBlockingSynchronousMethod = true forces synchronous JS-thread execution.

react-native-web sets Platform.OS to 'web'. Platform.select looks up the key matching the current platform; when no 'web' key exists it falls back to the special default key, which here maps to 'C'. It does not return undefined because default is always consulted before returning nothing.

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.

In React Native (which uses Yoga / Flexbox), the flex property sets a flex grow factor proportional to the sibling flex values. The total flex is 1 + 2 = 3, so the red child receives 1/3 of the available main-axis (horizontal) space and the blue child receives 2/3. flexDirection: 'row' makes the main axis horizontal; without explicit width the children still fill the row because their grow factors are non-zero. justifyContent would only matter if there were leftover free space, but here the flex factors consume all of it.

In React Navigation's Stack Navigator, navigate('ScreenName') searches the existing stack for a route with that name. If found, it pops back to that existing route rather than creating a new instance. Here Profile already sits in the stack below Settings, so calling navigate('Profile') pops Settings and focuses the existing Profile screen, yielding the stack [Home, Profile]. By contrast, push('Profile') would always create a new Profile instance on top, producing [Home, Profile, Settings, Profile]. Option (a) describes push behavior, (c) is wrong because navigate does change the active screen, and (d) is wrong because navigate never resets the entire stack (that would require navigation.reset).

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.

Starting with Android 11 (API 30), the OS enforces package-visibility filtering: an app can no longer see, query, or resolve intents targeting other installed apps by default. Linking.canOpenURL ultimately calls resolveActivity / queryIntentActivities on the package manager, which returns an empty result under these restrictions unless the calling app explicitly declares visibility via a <queries> element in AndroidManifest.xml — using <intent> to match the scheme, <package> to name the target, or <provider> for authority-based queries. Once the <queries> declaration is added, canOpenURL resolves correctly. Option A is wrong because custom schemes are supported; the issue is visibility, not scheme type. Option C is wrong because registering your own intent-filter for the scheme would make your app a handler, not enable detection of another app. Option D is wrong because ContentProviders are unrelated to custom-scheme intent resolution.

A synchronous JSI call is a direct C++ function invocation on the calling thread. Because the call originates from JavaScript, that thread is the JS thread—the same single thread that owns the jsi::Runtime. The native method body therefore runs on the JS thread, and every jsi::Runtime API it calls (creating objects, setting properties, calling functions) is safe without locks or dispatch. Option (b) is wrong because the implementation does not get to choose the thread for a synchronous call—it is the JS thread by definition. Option (c) is wrong because JSI runtimes (Hermes, V8) are single-threaded and explicitly not thread-safe; touching the Runtime from any non-JS thread is undefined behavior. Option (d) is wrong because TurboModule synchronous calls bypass the legacy bridge's asynchronous message-queue dispatch entirely—they do not run on the native-modules thread pool. The only scenario requiring synchronization is when the native method itself spawns work on another thread and that thread later accesses the Runtime, which must be posted back to the JS thread.

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.

With flexDirection: 'row', the main axis is horizontal and the cross axis is vertical. The parent's alignItems: 'center' would vertically center all children, but alignSelf: 'flex-start' on the middle child overrides that, snapping it to the start of the cross axis — which in a row layout is the top edge. The red and green boxes remain vertically centered; only the blue box is pinned to the top.

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.

(a) TRUE — navigate searches the current stack's state for an existing screen with the matching name; if found, it pops back to that instance rather than creating a duplicate. This is the key behavioral difference from push.

(b) TRUE — push unconditionally adds a new screen instance to the top of the stack, so you can have multiple copies of the same route (e.g., a deep chain of 'Profile' screens). This is why push is used for drill-down navigation that may repeat.

(c) TRUE — The beforeRemove navigation event fires before a screen is removed from the stack. Calling e.preventDefault() on the event object cancels the removal, which is the documented pattern for prompting users about unsaved changes or confirming a back/gesture action.

(d) FALSE — Tab Navigators (including Material Top Tabs) keep all tab screens mounted by default. A screen only unmounts on blur if you explicitly set unmountOnBlur: true in that screen's options. The default preserves component state across tab switches at the cost of memory.

In the New Architecture, TurboModules are backed by JSI rather than the asynchronous message queue of the legacy bridge. Codegen produces C++ bindings; when a TurboModule is instantiated, JSI creates a JS object whose methods are backed by native C++ function pointers installed via jsi::Object property accessors. A synchronous call (declared isSync: true in the spec) executes the C++ body directly on the JS thread, which then invokes the Obj-C++/JNI implementation. The return value is constructed as a jsi::Value in-place and handed back to the engine without any JSON serialization step or queue round-trip. Option (a) describes the legacy-bridge blocking model, which no longer applies once the bridge is disabled. Option (c) is wrong because isSync: true genuinely returns a plain value, not a Promise. Option (d) is wrong because TurboModules and Fabric are independent flags; synchronous methods work as long as TurboModules + JSI are enabled, regardless of whether the Fabric renderer is turned on.

getItemLayout is a function prop that returns { length, offset, index } for any item without mounting it. When it is provided, FlatList can calculate the pixel offset for item 400 as 50 * 400 = 20000 directly, making scrollToIndex both fast and accurate. initialScrollIndex only sets the starting scroll offset on mount and itself requires getItemLayout to work correctly for large lists. windowSize controls how many items are rendered in the viewport (a memory trade-off), not layout math. removeClippedSubviews clips off-screen views but does not provide measurement data. maxToRenderPerBatch controls batch rendering rate, not offset calculation.