React Interview Questions: Re-render Causes and Performance

The chart re-renders only because it happens to share a parent with the state that's changing — React re-renders a component's entire subtree by default whenever that component re-renders, siblings included, regardless of whether a given sibling's own props changed. searchTerm doesn't need to live at the page level at all; it's only ever read and written by the input, so colocating it there confines the re-render to the input's own small subtree and leaves the page (and the chart) untouched. b is a category error — useMemo memoizes a computed value inside a component, not a component itself, and does nothing to stop a parent-driven re-render; that's what React.memo is for, and even then it would only treat the symptom. c mischaracterizes key, which is an identity hint for reconciliation among siblings in a list, not a re-render-isolation mechanism. d is the trap this question tests: sibling re-renders are the default, but they follow from where state is placed and can be designed around, not an unavoidable law.

The opposite is true by default: React re-renders a component's entire subtree whenever that component re-renders, including every child, regardless of whether a given child's props changed. Nothing is skipped automatically. React.memo exists precisely because this isn't the default — it's an explicit opt-in a component author adds when they want React to compare that component's props and potentially skip re-rendering it.

A component re-renders when its state changes, its props change, or its parent re-renders (unless memoized). Mutating a normal variable does not schedule a render — React never sees the change.

React bails out when the new state is Object.is-equal to the current state — it may still re-render the component once before bailing, but it will not re-render children or commit changes. Setting the same primitive value is effectively a no-op.

The triggers are state change, new props, a consumed context value changing, or a parent rendering (unless the child is memoized and its props are unchanged). Plain variable mutation is invisible to React.

Defining () => save(text) inline means every render of Form produces a syntactically new function object. React.memo's shallow comparison checks each prop with Object.is, and Object.is reports two distinct function objects as different even if they'd behave identically — so onClick always reads as "changed," and memo re-renders SubmitButton on every Form render regardless of label. Wrapping the handler in useCallback(() => save(text), [text]) (stable whenever text hasn't changed) would let memo actually skip work. b is wrong — memo compares any prop type with Object.is, not just primitives; it's just that objects and functions rarely stay reference-equal across renders. c is wrong — "Save" is a string primitive, and Object.is compares primitives by value, so it's equal across renders. d is a red herring: memo behaves identically regardless of function-declaration syntax.

colors={['#4f46e5', '#16a34a', '#dc2626']} allocates a brand-new array literal on every render of Dashboard, even though its contents never change. React.memo's shallow comparison checks colors with Object.is, and two distinct array objects are never Object.is-equal no matter what they contain, so Chart's props always read as changed and memo re-renders it on every Dashboard render — including every tab switch, which has nothing to do with data or colors. Fix: hoist the array to a module-level constant (created once, outside the component) or wrap it in useMemo(() => [...], []) so the same reference is reused across renders.

React.memo's shallow comparison only inspects the props passed down by the parent; it says nothing about a context value a component subscribes to internally via useContext. React's own docs state this directly: a memoized component "will still re-render when a context that it's using changes" — memoization only concerns props from the parent. So every consumer of ThemeContext, memoized or not, re-renders when the provider's value changes, regardless of whether label changed. b and c invent a comparison React doesn't perform — context reads are never folded into the props shallow-equality check — and d invents a "resync once, then block" behavior that doesn't exist; context changes are never throttled by memo.

React.memo only gates one thing: whether a parent re-rendering with unchanged (shallowly-equal) props should force Child to re-render too. It has nothing to say about re-renders Child triggers on itself — its own useState/useReducer updates — or re-renders driven by data sources Child subscribes to directly, like context or an external store via useSyncExternalStore; all of those re-render Child regardless of what memo decided about its props. Passing Child the exact same primitive prop values as before is exactly the case memo is built to skip: same props, shallowly equal, so no re-render. A sibling re-rendering because its own state changed doesn't reach Child at all — a sibling's own state update re-renders that sibling's own subtree, not an unrelated sibling under the same parent.

Context has no concept of "the parts of the value a given consumer reads" — useContext subscribes to the whole value, and React re-renders every subscribed consumer whenever that value is a new reference (as determined by Object.is), regardless of which fields changed or which fields a particular consumer destructures. The standard mitigation is exactly what c describes — splitting one broad context into several narrower ones so a component only re-renders when the specific context it actually subscribes to changes. d is false and a common misconception: React.memo has no effect here, because these re-renders are triggered directly by useContext, not by a parent passing new props, which is the only path memo gates. e is false for the same reason as a/b: the comparison is on the value as a whole, so field-level selectivity isn't something plain context provides.

useReducer's dispatch checks the reducer's return value against the current state with the same Object.is comparison useState's setter uses. Returning the literal same reference — unmodified, not a copy or a spread — is Object.is-equal to the current state, so React bails out and does not schedule a re-render for that dispatch. This only works because the state is returned unchanged; a branch that spreads (return { ...state }) or copies and returns a new object produces a different reference and defeats the bail-out even when every field's value is identical.

Each click on "bump other" updates other, re-rendering Parent, which redefines onClick as a brand-new arrow function every time. React.memo compares every prop with Object.is, and onClick is a different function reference on each Parent render even though count stays 0, so the shallow comparison finds a changed prop and Child re-renders. That's 1 mount + 3 re-renders (one per click) = 4 total. If onClick were wrapped in useCallback(() => setCount(count + 1), [count]) (stable across renders where count doesn't change), the three clicks would produce zero additional Child renders, since both count and onClick would be Object.is-equal to their previous values.

Each tick updates App's tick state, re-rendering App, which evaluates value={{ count }} fresh — a brand-new object every render, even though count's own value (0) never changes. useContext compares the previous context value to the new one as a whole via Object.is, and two different object references are never equal no matter what fields they contain, so CountDisplay re-renders on every App render regardless of whether count itself changed. That's 1 mount + 3 re-renders = 4. Wrapping the provider value in useMemo(() => ({ count }), [count]) would give it a stable reference across renders where count doesn't change, and the three ticks would produce zero additional CountDisplay renders.

value={{ user, login, logout }} builds a new object literal on every render of AuthProvider, so the context value has a different reference every time — even on renders where user and the behavior of login/logout haven't meaningfully changed. Because useContext compares the previous and next context values with Object.is, a changed reference is all it takes: every consumer re-renders on every AuthProvider render, regardless of which field it actually reads. login and logout are also redefined as new function objects every render, compounding the problem for any consumer that only cares about calling them. Fix: memoize the value with useMemo(() => ({ user, login, logout }), [user, login, logout]), and wrap login/logout in useCallback so their references stay stable too — then the value object's reference only changes when one of its real inputs changes.

key={index} ties each TodoRow's identity to its position, not to which todo it represents. Deleting the first todo shifts every remaining todo down one index, so the component instance that used to render at index 1 (currently in edit mode) is now matched against the todo that used to be at index 2, because both are "key=1" as far as React can tell across renders — same key means React reuses the same component instance and its state (isEditing: true) in place, only updating its data. The result: the third todo inherits the second todo's edit state, while the second todo's own edit state is lost (it inherits whatever index 0's instance had). Fix: key={todo.id}, so identity follows the data itself rather than its position, and a delete or reorder can never cross state between items.

This is one of the most commonly misunderstood boundaries of React.memo in interviews: it's a props-in comparison, not a general 're-render blocker.' It gates exactly one re-render trigger — a parent re-rendering with the same shallow props — and has zero effect on the other triggers (own state, context, external stores) because those don't go through the parent-props path memo inspects at all.

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.

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.