React useState interview questions

The statement is false. A useState setter does not change the local count variable in the currently executing render. React queues the update and schedules a re-render, so count keeps its old value on the next line. The new value only appears when the component re-renders and useState returns it on that later call.

useState(0) returns a [value, setter] pair; destructuring names them count and setCount by convention. Calling setCount schedules a re-render with the new value.

useState returns a two-element array whose first element is the current state value (initialized to initialValue on the first render) and whose second element is the setter function used to update that state. By convention we destructure it as const [state, setState] = useState(initialValue). It is not an object, a single value, or a Promise.

React convention names the setter returned by useState by prefixing the state variable name with set, so for a state variable named count the conventional setter name is setCount. Any valid JavaScript identifier would work at runtime, but setCount is the widely-followed community convention.

useState(0) initializes the state variable count to 0 on the first render. The JSX <p>{count}</p> therefore renders the number 0 as the text content of the paragraph, so the displayed value is 0.

useState returns a two-element array. The first element is the current state value, and the second element is a function (the state setter) that updates that state and triggers a re-render. This is why it is conventionally destructured, as in const [count, setCount] = useState(0).

On the initial render, useState uses the provided initial value (or calls the initializer function). On every subsequent render, useState ignores the argument entirely and returns the current state value instead.

All three setCount calls run inside the same click handler, and each reads the count value from that render's closure, which is 0. Each call therefore enqueues the same update, setCount(0 + 1), i.e. setCount(1). React batches these updates within the event, so the final state is 1 and the button re-renders showing 1, not 3.

The updater form setCount(c => c + 1) receives the latest pending state, so it is safe across batching and stale closures. Reading the count variable can use a stale value.

The handler changes the age property of the existing state object in place and then calls setUser with that same object. React uses an identity check (Object.is) to decide whether state changed; since the reference is unchanged, it treats the update as a no-op and the rendered age does not update. The fix is to create a new object, such as setUser(prev => ({ ...prev, age: prev.age + 1 })), so the reference differs and React re-renders with the new value.

A React state setter accepts either a new value or an updater function. When the next state depends on the previous state, passing an updater function makes React call it with the latest queued state value. Passing a computed value instead uses whatever state was captured in the current render's closure, which can be stale when several updates are batched in one event handler.

State setters schedule a re-render; they do not mutate the existing count binding. Within the same render/handler count keeps its current value, and the updated value is only visible in the next render. This is why updater functions are needed for sequential updates.

useState(init) evaluates init every render but only uses it once; useState(() => init) defers the work to mount. Both yield the same initial state.

A controlled input's displayed value comes from state, so the keystroke fires onChange, which sets state, which triggers a re-render that feeds the new value back into the input. Skipping setState would leave the input frozen at its old value.

On the initial render n is 0, and the closure in handleClick captures that value. The two direct calls setN(n + 1) both compute 0 + 1 = 1, so they queue the value 1 twice; they do not see each other's results because they read the stale n from the closure. The third call passes an updater function, which React applies to the pending queue in order: it receives the latest pending value 1 as prev and returns 1 + 1 = 2. React batches all three updates within the same event handler into a single re-render, so the button shows 2.

The lazy initializer () => count * 2 runs only on mount, when count is 0, so double starts at 0. Each click queues two functional setCount updaters that chain on the previous value, so count rises by 2 per click. The setDouble(d => d + count) call reads count from the render's closure, which is the value rendered before that click: 0 on the first click and 2 on the second. After click 1, count is 2 and double is 0 + 0 = 0. After click 2, count is 4 and double is 0 + 2 = 2. The button therefore displays 4-2.

A useState setter replaces the state wholesale; it does not shallow-merge the way the old class setState did. Line 7 calls setForm with a new single-key object { [field]: value }, so form becomes an object that contains only the field just typed into, and every other field is discarded (their inputs then render as undefined/empty). The fix is to spread the previous state, for example setForm(prev => ({ ...prev, [field]: value })), so the other keys are carried forward.

Both calls close over the same render's count (0), so each computes 0 + 1 and the state ends at 1. The updater form setCount(c => c + 1) would reach 2.

This distinction trips people up because it sounds like two different mechanisms when it's really one mechanism applied to two different calling conventions. Interviewers use it to probe whether a candidate actually understands Object.is-by-reference versus deep equality, not just the surface behavior.

All four setCount calls in the handler are queued and batched into one re-render. The closure's count is 0 for the whole handler, so both direct-value calls compute 0 + 1 = 1. Processing the queue in order from the base state 0: the first call sets the value to 1; the first functional update receives prev = 1 and returns 2; the second functional update receives prev = 2 and returns 3; the final direct-value call sets the value to the stale 0 + 1 = 1, overwriting the earlier functional-update work. The rendered button therefore shows 1, not 3 or 4.

The effect has an empty dependency array, so it runs only once on mount, and the interval callback closes over the count value from that first render, where count is 0. Line 8, setCount(count + 1), therefore always computes 0 + 1 and sets the state to 1 on every tick. Re-renders do not re-create the interval because the effect does not re-run, so the stale closure persists and the display stays at 1. The fix is the functional updater setCount(prev => prev + 1), which receives the latest committed state from React rather than a captured variable.

React applies the exact same Object.is bail-out to both hooks — "if the new value is Object.is-equal to the current state, skip the re-render" is one rule, not two different ones for the two hooks. What differs here is what the two call sites hand React. setState(state) passes the literal same object back, and Object.is(obj, obj) is true, so it bails out. The reducer's { ...state } spread constructs a brand-new object every dispatch, and even though its fields are equal, Object.is on two distinct object references is always false, so React proceeds with the re-render. This is a real production trap: a reducer that always spreads never gets a free bail-out for a no-op action, even when nothing logically changed — only an unmodified return state; does. b is false (useReducer does bail out — the docs cover it explicitly); c misdescribes what's compared (the resulting state, not action.type); d is wrong — useState's bail-out applies to any value type via Object.is, object or primitive, not just primitives.

The effect has an empty dependency array, so the interval callback closes over the initial count value of 0 for the component's lifetime. Each tick therefore calls setCount(0 + 1), i.e. setCount(1). On the first tick count becomes 1, while multiplier (updated with a functional updater that always sees the latest state) becomes 2; React batches these into one render, which prints 1 × 2 = 2. On every later tick setCount(1) leaves count at 1, but setMultiplier(m => m + 1) still changes the multiplier to 3, 4, 5, 6, so the component re-renders each time and prints 3, 4, 5, 6. The mount render prints 0 × 1 = 0. The output is therefore 0, 2, 3, 4, 5, 6. Whether React takes its eager-bailout path for the redundant count update does not change the printed values, because the multiplier change forces a render on every tick.

On initial render, count is 0, so the useEffect logs render: 0. The click handler's closure captures count = 0 from this render's scope. The first setCount(count + 1) enqueues a replace update with value 1 (0 + 1). The second setCount(count + 1) enqueues another replace update, also with value 1 — the same stale 0, not the intermediate 1, because the variable count is not reassigned within the handler. The third setCount((prev) => prev + 1) enqueues a functional update that React applies to the latest pending state. Processing the batch in order: replace → state = 1, replace → state = 1, functional → state = 1 + 1 = 2. One re-render occurs with count = 2. The useEffect fires (count changed 0 → 2) and logs render: 2. Total output is two lines: render: 0 then render: 2.

The effect's dependency array is [query], so the effect body runs only when query changes. Inside the effect, pollCount is captured from the closure at the time the effect ran — its initial value of 0. Every subsequent call to setPollCount(pollCount + 1) evaluates 0 + 1 = 1, so the counter is reset to 1 on every poll and never advances. The fix is setPollCount((prev) => prev + 1), a functional update that React applies to the most recent committed state. Wrapping api.fetch in useCallback is unnecessary — the function is only used inside the effect and is not a dependency that changes behavior. setData(result) is a straightforward full replacement, not a merge issue. Adding pollCount to the dependency array would be harmful: the effect would tear down and recreate the interval on every count change, disrupting the 5-second cadence and defeating the purpose of the polling architecture.