React interview questions and answers

Question 1

What is React, why use it, and when should you not?

Accepted Answer

Answer: React is a JavaScript library (not a full framework) for building user interfaces, made by Facebook. You describe what the screen should look like for a given state, and React keeps the actual DOM in sync as the state changes. Why teams use it: you build the UI from small reusable components; you write what the UI should be, not step-by-step DOM instructions; the Virtual DOM makes updates fast; and there is a huge ecosystem. When not to use it: a simple static site (plain HTML and a little CSS is lighter and faster), a page where you would ship a large JavaScript bundle for very little interactivity, or a team that is not comfortable with JavaScript. 'HTML versus React' is really 'do the interactivity and reuse justify the bundle and the build step'. Analogy: React is like a spreadsheet. You write formulas (what each cell should show given the data), and the sheet recalculates the visible cells when the data changes. You never manually repaint cells. In an interview: React is a UI library where you declare what the screen should be for the current state and it updates the DOM for you, built from reusable components. Skip it for simple static pages or when the interactivity does not justify the bundle and build step.

Question 2

What is a single-page application (SPA), and when does it feel slow?

Accepted Answer

Answer: A single-page application loads one HTML page once, and after that JavaScript updates the content in place as the user navigates, with no full page reloads. React apps are usually SPAs. The upside is fast, app-like navigation after the first load, because moving between 'pages' is just swapping components, not fetching a new document. When it feels slow: the initial load. The browser has to download, parse, and run a large JavaScript bundle before it can show anything useful, so the first screen can be blank for a moment. Fixes: code splitting so each route loads only its own JavaScript, server-side rendering or static generation for the first paint, and lazy-loading heavy parts. Analogy: an SPA is like a stage play with one set that the crew rearranges between scenes, versus building a whole new theatre for each scene. Rearranging is fast; building the first theatre takes a while. In an interview: An SPA loads once and then JavaScript swaps content with no reloads, so in-app navigation is instant. It feels slow on the first load because a big JavaScript bundle must download and run first, which you fix with code splitting and server or static rendering.

Question 3

What is the difference between client-side and server-side rendering in React, and what is hydration?

Accepted Answer

Answer: Client-side rendering (CSR): the server sends a nearly empty HTML file plus a JavaScript bundle. The browser runs the JavaScript, which builds the whole UI. Slower first paint, no HTML for search engines to read without extra work, but simple to host. Server-side rendering (SSR): the server runs your React components and sends fully formed HTML. The user sees content immediately, and crawlers get real HTML. Then the JavaScript bundle loads and 'hydrates' the page. Hydration is React attaching to the server-rendered HTML: it walks the existing DOM, matches it to the component tree, and wires up the event handlers and state so the static HTML becomes interactive. Until hydration finishes, buttons on an SSR page do not respond yet. Frameworks like Next.js do SSR and hydration for you. Analogy: SSR sends a fully printed newspaper you can read right away. Hydration is the moment the paper becomes a tablet: same content, now the buttons work. In an interview: CSR ships an empty shell and lets JavaScript build the UI. SSR sends real HTML from the server for a fast first paint and SEO. Hydration is React attaching event handlers and state to that server HTML to make it interactive, and the page is not clickable until it completes.

Question 4

What are React Server Components (RSC)?

Accepted Answer

Answer: Server Components are components that run only on the server and never ship to the browser as JavaScript. The server renders them and sends a lightweight serialized description of the result, which the client slots into the page. Their code, and any libraries they use, stay on the server. Why they matter: they cut the JavaScript bundle. A component that formats a date or reads a database does not need to be interactive, so there is no reason to send its code to the browser. Rules: Server Components can fetch data directly (await a database call) and cannot use state, effects, or event handlers. Anything interactive must be a Client Component (marked "use client"). A typical app is mostly Server Components with small Client Components for the interactive bits. Analogy: the server does the heavy prep in the kitchen and sends out a finished plate. Only the few things the diner actually interacts with (the pepper grinder) come to the table. In an interview: Server Components run only on the server and send a serialized result, not their code, so they shrink the bundle. They can fetch data directly but cannot use state, effects, or handlers. Interactive parts stay as Client Components, and an app mixes mostly server with small client pieces.

Question 5

What is JSX, and how does the browser actually run it?

Accepted Answer

Answer: JSX is a syntax extension that lets you write HTML-like markup inside JavaScript. It is not HTML and not valid JavaScript on its own. The browser cannot run JSX. A build tool (Babel, or the compiler in Vite / Next.js) transforms every JSX tag into a plain function call: React.createElement(type, props, ...children), or the newer automatic-runtime equivalent. That call returns a plain object (a React element) describing what to render. Since React 17 you no longer need import React from "react" just to use JSX, because the new transform imports the helper itself. You still import React (or specific hooks) when you use its APIs. Analogy: JSX is shorthand a translator expands before the computer reads it.

Hi

is just a friendlier way to write 'make an h1 element containing Hi'. In an interview: JSX is HTML-like syntax inside JavaScript that a build tool compiles into React.createElement calls, which return plain objects describing the UI. Browsers never see JSX. Since React 17 the transform is automatic, so you do not import React just for JSX.

Question 6

What is the Virtual DOM, and how do diffing and reconciliation work?

Accepted Answer

Answer: The Virtual DOM is a lightweight copy of the UI tree kept in memory as plain JavaScript objects. Changing real DOM nodes is slow, so React works out changes on the cheap in-memory copy first. The cycle when state changes: 1. Render: React calls your components again and builds a new Virtual DOM tree. 2. Diffing (reconciliation): React compares the new tree to the previous one, node by node, using fast heuristics (same type = update in place, different type = replace; lists are matched by key). 3. Commit: React applies only the minimal set of real DOM changes it found, in one batch. So you re-describe the whole UI on every change, and React figures out the small real update. Analogy: an editor marking up a new draft against the old one. They do not retype the whole document; they circle only the sentences that changed and hand those to the typesetter. In an interview: The Virtual DOM is an in-memory object tree. On a state change React re-renders to a new tree, diffs it against the previous one with type and key heuristics, and commits only the minimal real DOM updates in a batch. You describe the whole UI; React makes the small change.

Question 7

Why do lists rendered in React need a key prop?

Accepted Answer

Answer: When React diffs a list, it needs to know which item is which between renders. The key is a stable id you give each item so React can tell 'this is the same item, just moved' from 'this is a new item'. Without keys (or with the array index as the key), if you insert or reorder items, React matches them by position and can attach the wrong state to the wrong row, reuse the wrong DOM node, or re-render more than needed. A classic bug: an input's typed value jumps to a different row after you delete a row above it. Use a real unique id from your data (item.id). Only use the index as a key if the list never reorders and items are never inserted or removed in the middle. Analogy: keys are name tags at a conference. If people swap seats, you still know who is who by the tag. Numbering by seat instead (the index) means moving one person relabels everyone. In an interview: Keys let React match list items across renders so it moves the right DOM node and keeps state with the right item. Use a stable unique id from the data. The array index is safe only for a static list that never reorders or has middle inserts.

Question 8

What is a component, and what is the difference between class and function components?

Accepted Answer

Answer: A component is a reusable, self-contained piece of UI, defined as a function (or, in older code, a class) that returns what to render. Function components: a plain function that takes props and returns JSX. State and lifecycle come from hooks (useState, useEffect). Less code, no this, easy to test and reuse. This is the modern default. Class components: extend React.Component, put markup in a render() method, hold state in this.state, and use lifecycle methods (componentDidMount, componentDidUpdate, componentWillUnmount). More verbose, the this keyword trips people up, and harder to share logic between components. New code uses function components. You still see classes in older codebases and in error boundaries, which currently must be classes. Analogy: function components are the new lightweight tool; class components are the older, heavier version that does the same job with more ceremony. In an interview: A component is a reusable unit of UI that returns JSX. Function components use hooks for state and lifecycle and are the modern default: less code, no this. Class components use render() and lifecycle methods and are legacy, kept mainly for older code and error boundaries.

Question 9

What is the difference between state and props?

Accepted Answer

Answer: Props are data passed INTO a component from its parent. They are read-only inside the component: you never change your own props. They are how data flows down the tree. State is data a component owns and manages itself. It can change over time (via setState or a useState setter), and when it changes the component re-renders. Rule of thumb: if a value is passed from above and the component just displays it, it is a prop. If the component needs to remember something and update it (an input's value, whether a menu is open), it is state. A parent can pass its state down to a child as a prop, and pass a setter down so the child can request a change. Analogy: props are the ingredients handed to a chef (they use them, they do not rewrite the order). State is the chef's own notes about how the dish is coming along, which they update as they cook. In an interview: Props are read-only inputs passed down from a parent; state is data a component owns and can change, triggering a re-render. Display-only data from above is a prop; something the component must remember and update is state. Parents pass state down as props and pass setters to let children request changes.

Question 10

What is a controlled input, and how would you handle a large form with complex validation?

Accepted Answer

Answer: A controlled input is one whose value is driven by React state: value={x} plus onChange to update x. React is the single source of truth. An uncontrolled input keeps its own value in the DOM and you read it with a ref when needed. For a large form, controlling every field by hand becomes a lot of re-renders and boilerplate. Practical approach: 1. Use a form library (React Hook Form, Formik). React Hook Form uses uncontrolled inputs with refs, so typing in one field does not re-render the whole form. 2. Define validation as a schema (Zod, Yup) so rules live in one place and run on blur and on submit. 3. Split the form into smaller components and validate per section. 4. Show errors next to fields, disable submit until valid, and validate on the server too. Analogy: a controlled input is a thermostat: the dial position IS the setting. For a big form you hire a form manager (the library) instead of wiring every dial yourself. In an interview: A controlled input binds its value to state with value and onChange. For a large form I use a form library like React Hook Form so fields stay uncontrolled and typing does not re-render everything, plus a schema library for validation rules in one place, split into sections, with server-side validation as the backstop.

Question 11

What does it mean to "lift state up", and why do it?

Accepted Answer

Answer: Lifting state up means moving a piece of state from a child component to the closest common parent of the components that need it, then passing it back down as props. You do it when two sibling components need to share or stay in sync with the same value. A child cannot see its sibling's state directly, so the state moves up to their shared parent, which passes the value down to both and passes a setter down so either child can update it. Example: a search box and a results list. Instead of the box holding the query, the parent holds it, gives it to both, and the list re-renders when the box updates it. Analogy: two kids arguing over a shared toy. The parent takes the toy, and now both ask the parent for it. One source of truth, no conflict. In an interview: Lifting state up is moving shared state to the nearest common parent and passing it down as props, plus a setter. You do it when sibling components need the same value, since a child cannot read a sibling's state directly. It gives one source of truth.

Question 12

What is the component lifecycle, and how do function components cover it?

Accepted Answer

Answer: A component goes through three phases: Mounting: it is created and added to the DOM for the first time. Updating: it re-renders because its state or props changed. Unmounting: it is removed from the DOM. Class components have named methods for these: componentDidMount (good for fetching data), componentDidUpdate (react to changes), componentWillUnmount (clean up listeners and timers). Function components use useEffect instead: - useEffect(fn, []) runs once after mount. - useEffect(fn, [dep]) runs after mount and whenever dep changes. - returning a function from the effect runs it on unmount (and before the next run) for cleanup. Analogy: born, living (and changing), and leaving. Class components have three separate doors for these; useEffect is one door that you configure with a dependency list. In an interview: Components mount, update, and unmount. Class components use componentDidMount, componentDidUpdate, and componentWillUnmount. Function components use useEffect: an empty dependency array for mount, a dependency for updates, and a returned function for cleanup on unmount.

Question 13

When does a React component re-render?

Accepted Answer

Answer: A component re-renders when: 1. Its own state changes (a useState setter is called with a different value). 2. Its parent re-renders. By default, when a component renders, React re-renders all of its children, whether or not their props changed. 3. A context it consumes changes value. Re-rendering means React calls the component function again to get fresh JSX, then diffs it against the previous output. A re-render does not always touch the real DOM; if the output is the same, nothing changes on screen. But the function work and the diff still cost time, which is why unnecessary re-renders matter in large trees. Analogy: when a manager gets new information they call a meeting, and by default the whole team attends even if the news does not affect them. In an interview: A component re-renders when its state changes, when its parent re-renders (children re-render by default), or when a consumed context changes. Re-rendering re-runs the function and diffs the output; it only touches the DOM if the output differs, but the work still adds up in big trees.

Question 14

What causes slow rendering in React, and how do you fix unnecessary re-renders?

Accepted Answer

Answer: The usual causes: 1. A parent re-rendering re-renders its whole subtree, including expensive children whose props did not change. 2. Heavy computation done directly in the component body on every render. 3. Large lists rendering thousands of DOM nodes at once. Fixes: - React.memo(Component): skips re-rendering a child if its props are unchanged (shallow compare). - useMemo for an expensive calculated value, useCallback for a function passed as a prop, so their references stay stable and React.memo actually works. - Move state down: put state in the smallest component that needs it, so fewer things re-render. - Virtualise long lists (react-window) so only visible rows render. - Give lists stable keys. Measure first with the React DevTools Profiler; do not scatter memo everywhere by guess. Analogy: if one small change makes the whole office redo their work, you either tell people to ignore updates that do not concern them (memo), or you reorganise so the change only reaches the desk it matters to (move state down). In an interview: Slow rendering usually comes from a parent re-rendering a big subtree, heavy work in the render body, or huge lists. Fix with React.memo to skip unchanged children, useMemo and useCallback to keep props stable so memo works, moving state down, and virtualising long lists. Profile with React DevTools before adding memo.

Question 15

Why does my useEffect run twice, or run in an infinite loop?

Accepted Answer

Answer: Two different problems. Runs twice on mount (in development): React 18 Strict Mode deliberately mounts, unmounts, and remounts every component once in development to surface missing cleanup. It does not happen in production. If your effect breaks when run twice, it is missing a cleanup function or is not idempotent, which is the bug it is pointing at. Infinite loop: the effect updates state that is also in its dependency array, or a dependency is a value that is a new reference on every render (an object, array, or function created in the body). Effect runs, sets state, component re-renders, dependency 'changed', effect runs again, forever. Fixes: only depend on primitive values or stable references, wrap object/function deps in useMemo/useCallback, use the updater form of setState, or move the value out of the dependency list if it truly should not retrigger. Analogy: an infinite loop is a light switch wired to a motion sensor that the light itself triggers. The effect causes the change it is watching for. In an interview: Running twice on mount is React 18 Strict Mode in development testing your cleanup; it is not in production. An infinite loop means the effect updates a dependency it also lists, or a dependency is a fresh object or function each render. Depend only on stable values, memoise object and function deps, and use the setState updater form.

Question 16

What is a hook, and what are the rules of hooks?

Accepted Answer

Answer: A hook is a function that lets a function component 'hook into' React features like state, lifecycle, and context. The built-in ones include useState, useEffect, useContext, useReducer, useRef, useMemo, useCallback, useLayoutEffect. Their names start with 'use'. The rules: 1. Only call hooks at the top level of a component or another hook. Never inside a loop, a condition, or a nested function. 2. Only call hooks from React function components or custom hooks, not from regular functions or class components. Why rule 1 matters: React tracks hooks by call order, not by name. If you call them conditionally, the order changes between renders and React attaches the wrong state to the wrong hook. The ESLint plugin react-hooks enforces this. Analogy: React keeps a numbered list of your hooks. If you sometimes skip one, all the numbers after it shift and point to the wrong thing. In an interview: A hook is a 'use'-prefixed function that gives a function component access to state, effects, and context. The rules: call them only at the top level, never conditionally or in loops, and only from components or custom hooks. React identifies hooks by call order, so a conditional call misaligns the state.

Question 17

What is useState, and how is it different from class component state?

Accepted Answer

Answer: useState adds one piece of state to a function component. It returns the current value and a setter: const [count, setCount] = useState(0). Calling the setter with a new value schedules a re-render. Differences from class state: 1. Multiple variables: with hooks you call useState once per independent value. Class state is usually one big object. 2. Replace vs merge: the useState setter REPLACES the value. this.setState in a class MERGES the object you pass into the existing state. 3. Updater form: when the new value depends on the old, pass a function: setCount(c => c + 1). This avoids bugs from a stale value captured in a closure. Analogy: class state is one big form you keep editing. useState is a set of separate sticky notes, and replacing a note means writing a whole new one, not editing part of it. In an interview: useState adds one state value plus a setter, and calling the setter re-renders. Unlike class state it is one call per independent value, the setter replaces rather than merges, and you use the updater function form when the new value depends on the old.

Question 18

What is useEffect, and how do the dependency array and cleanup function work?

Accepted Answer

Answer: useEffect runs side effects: things outside rendering, like fetching data, setting up a subscription or timer, or manually touching the DOM. It runs after the component has rendered and the screen is painted. The dependency array controls when it runs: - No array: after every render. - []: once, after the first render. - [a, b]: after the first render, and again whenever a or b changes. The cleanup function is what you return from the effect. React runs it before the effect runs again, and when the component unmounts. Use it to remove listeners, clear timers, and cancel subscriptions or requests, so you do not leak memory or update an unmounted component. Analogy: useEffect is 'after you have drawn the screen, also do this'. The cleanup is 'and before you do it again, or leave, undo the last one'. In an interview: useEffect runs side effects after render. The dependency array decides when: none means every render, empty means once, and a list means whenever those values change. The returned cleanup function runs before the next effect and on unmount, to remove listeners, clear timers, and cancel work.

Question 19

What is useRef, and how is it different from useState?

Accepted Answer

Answer: useRef returns a mutable object { current: ... } that stays the same between renders. Changing ref.current does NOT cause a re-render. Two main uses: 1. Get a DOM element: <input ref={inputRef} />, then inputRef.current.focus(). 2. Hold a mutable value across renders without re-rendering: a timer id, the previous value of a prop, a flag like 'has this already run'. Difference from useState: useState is for values that should appear on screen, so changing them re-renders. useRef is for values you need to remember but that do not affect the output, so changing them is silent. If you find yourself reading a ref during render to decide what to show, it probably should have been state. Analogy: useState is what is written on the whiteboard everyone looks at (change it and people react). useRef is a note in your pocket (you can update it any time, nobody notices). In an interview: useRef gives a persistent mutable object whose changes do not re-render. Use it to reference a DOM node or to keep a value like a timer id or previous prop across renders. useState is for values that should show on screen and re-render when changed; useRef is for values that should not.

Question 20

What is useContext, and what problem does it solve?

Accepted Answer

Answer: useContext lets a component read a value from a React Context without passing it down through every level of the tree. It solves 'prop drilling': threading a prop through many components that do not use it, just to reach a deep child. Three steps: 1. Create: const ThemeContext = createContext(defaultValue). 2. Provide: wrap a part of the tree in <ThemeContext.Provider value={theme}>. 3. Consume: any component inside calls const theme = useContext(ThemeContext). Good for app-wide values that many components need: the current user, theme, language, a feature-flag set. Note: when the context value changes, every consumer re-renders, so do not put frequently-changing state in one big context. Analogy: instead of passing a note hand to hand down a long line of people, you put it on a noticeboard in the room and anyone can read it directly. In an interview: useContext reads a value from a Context provider directly, skipping the intermediate components, which solves prop drilling. You create a context, wrap a subtree in its Provider, and consume it with useContext. It suits app-wide values like user, theme, and language, and every consumer re-renders when the value changes.

Question 21

What is useReducer, and when do you use it instead of useState?

Accepted Answer

Answer: useReducer manages state with a reducer function: given the current state and an 'action' object, it returns the next state. You get [state, dispatch], and you call dispatch({ type: "increment" }) to trigger a change. Use it over useState when: 1. The next state depends on the previous state in non-trivial ways. 2. You have several related pieces of state that change together (a form, a wizard, a data-fetch status of loading/data/error). 3. The update logic is complex enough that you want it in one testable function outside the component. It is the same idea as Redux, but local to one component. Analogy: useState is a light switch. useReducer is a control panel with labelled buttons ('start', 'stop', 'reset'), where one function decides what each button does to the machine. In an interview: useReducer holds state and updates it through a reducer function that takes the current state and an action and returns the next state, via dispatch. Use it when updates depend on previous state, several fields change together, or the logic is complex enough to want it in one testable function. It is local Redux.

Question 22

What do useMemo and useCallback do, and when are they worth using?

Accepted Answer

Answer: useMemo(fn, deps) remembers the RESULT of calling fn, and only recomputes it when a value in deps changes. Use it for a genuinely expensive calculation. useCallback(fn, deps) remembers the FUNCTION itself, returning the same function reference until deps change. useCallback(fn, deps) is just useMemo(() => fn, deps). Why references matter: in JavaScript {} !== {} and () => {} !== () => {}. A child wrapped in React.memo, or an effect with a function/object dependency, sees a 'new' prop every render if you recreate it in the body. useMemo and useCallback keep the reference stable so the optimisation actually works. When NOT worth it: cheap calculations, or when the deps change every render anyway. They cost memory and a comparison each render, so overusing them can make things slower, not faster. Measure first. Analogy: useMemo saves the answer to a hard sum. useCallback hands out the same phone number instead of a new one each time, so the person you gave it to does not think you moved. In an interview: useMemo caches a computed value and useCallback caches a function reference, each recomputing only when their dependencies change. They matter because new objects and functions break React.memo and retrigger effects. Use them for expensive work or to keep props stable, not everywhere, since they have a cost.

Question 23

How do you write a custom hook, and why?

Accepted Answer

Answer: A custom hook is a function whose name starts with 'use' and that calls other hooks. It lets you extract stateful logic from a component so several components can share it, without sharing state (each call gets its own state). You are not sharing a value, you are sharing behaviour: 'how to fetch and cache data', 'how to read window size', 'how to sync a value to localStorage'. The component stays focused on what to render. It must follow the rules of hooks, since it calls hooks itself. Analogy: a custom hook is a recipe card for a bit of logic. Every kitchen that follows it gets its own pot of soup, not a shared one. In an interview: A custom hook is a 'use'-prefixed function that calls other hooks to package reusable stateful logic. Each component that calls it gets its own independent state; you are sharing behaviour, not a value. It keeps components focused on rendering and must follow the rules of hooks.

Question 24

How do you fetch data in React, and how do you re-fetch it on demand, for example from a refresh button?

Accepted Answer

Answer: The basic pattern is useEffect: fetch when the component mounts or when a key value (like an id) changes, store the result in state, and handle loading and error states. Always cancel or ignore the response on unmount to avoid setting state on a gone component. To re-fetch on demand, you need to retrigger the effect or call the fetch function again. Common ways: 1. Keep the fetch in a useCallback and call it from both the effect and the button's onClick. 2. Add a 'refreshKey' number to state and to the effect's dependency array; the button does setRefreshKey(k => k + 1). 3. Change the child's key prop to force it to remount and refetch. In real apps a data library (TanStack Query, SWR, or RTK Query) handles fetching, caching, loading/error state, and exposes a refetch() function, so you rarely write this by hand. Analogy: the effect is 'fetch when you arrive'. A refresh button needs a way to say 'pretend you just arrived again', which is what bumping a key or calling the function does. In an interview: Fetch in useEffect keyed on the id, store in state, handle loading and errors, and cancel on unmount. To re-fetch on a button click, call the same fetch function again, bump a refreshKey in the dependency array, or change a key prop to remount. In practice a data library like TanStack Query gives you a refetch function.

Question 25

What is prop drilling, and what are the ways to avoid it?

Accepted Answer

Answer: Prop drilling is passing a prop through many layers of components that do not use it, only so a deep child can receive it. It clutters every component in the path and makes refactoring painful. Ways to avoid it: 1. Component composition: pass the deep component as children or as a prop from where the data lives, so it does not travel through the middle. Often the simplest fix. 2. Context: for values many parts of the app need (user, theme, locale). Do not use it for everything, since every consumer re-renders on change. 3. A state management library (Redux, Zustand, Jotai) for larger shared state with many readers and writers. Reach for composition first, context for a few app-wide values, and a library only when the shared state is genuinely large. Analogy: handing a parcel through ten people to reach the back of the room. Better to walk it there yourself (composition), post it on a noticeboard (context), or use an internal mail system (state library). In an interview: Prop drilling is threading a prop through components that do not use it to reach a deep child. Fix it with component composition first (pass the node down from where the data is), context for a few app-wide values, or a state library for large shared state with many readers.

Question 26

Do you need Redux? How do Context, Redux, and other state tools compare?

Accepted Answer

Answer: Most apps do not need Redux any more. Decide by what the state is: Local state (useState / useReducer): anything only one component and its children need. Start here. Context: a small number of rarely-changing app-wide values (auth user, theme, locale). It is a delivery mechanism, not a state manager, and every consumer re-renders when the value changes. Server state (TanStack Query, SWR, RTK Query): data that lives on the server. These handle caching, refetching, loading and error states, and deduplication. Most 'global state' is actually server state, and this is where they belong. Client global state library (Redux Toolkit, Zustand, Jotai): genuinely global client state with complex updates, many writers, time-travel debugging, or middleware needs. Redux Toolkit is far less boilerplate than old Redux; Zustand and Jotai are lighter still. Rule: local state, plus a server-state library, covers most apps. Add a global store only when you actually have complex shared client state. Analogy: you do not rent a warehouse to store one box. useState is a drawer, context is a shared shelf, a query library is a fridge that restocks itself, and Redux is the warehouse, only worth it when you truly have warehouse-scale stuff. In an interview: Usually no. Use local state by default, context for a few app-wide values, and a server-state library like TanStack Query for anything from the server, which is most 'global' state. Add Redux Toolkit or Zustand only for genuinely complex global client state with many writers.

Question 27

What is the difference between useEffect and useLayoutEffect?

Accepted Answer

Answer: Both run effects tied to render, with the same API. The difference is timing. useEffect runs after the browser has painted the screen. It is asynchronous and does not block the visual update. This is the default and what you should use almost always. useLayoutEffect runs synchronously after React updates the DOM but BEFORE the browser paints. Use it only when you need to read layout (measure an element) and change it before the user sees a flicker, for example positioning a tooltip relative to its target. The cost: useLayoutEffect blocks painting, so heavy work in it makes the page feel janky. On the server it does not run and warns, so guard it or prefer useEffect. Analogy: useEffect is 'after the photo is printed, make a note'. useLayoutEffect is 'after arranging the shot but before the shutter clicks, nudge the subject', useful to avoid a bad photo but it holds up the shoot. In an interview: useEffect runs after paint and does not block it, and is the default. useLayoutEffect runs after the DOM update but before paint, so use it only to measure and adjust layout without a visible flicker, like positioning a tooltip. It blocks painting, so keep it light.

React interview preparation

React basics

JSX and the Virtual DOM

Components, state and props

Rendering and performance

Hooks

Patterns and data