105 道问答题，一道一卡105 questions, one card each

In one line — say this precisely: useEffect is not a replacement for lifecycle methods; it is a different way of thinking about synchronising side effects — you declare which values a side effect depends on, and it re-runs when they change.

But the table has a trap — useEffect(fn, []) is not quite componentDidMount: the first runs asynchronously after the browser paints, the second is synchronous. So measuring the DOM in a useEffect and then changing styles will flash; that case wants useLayoutEffect.

More important: stop writing effects with a lifecycle mindset. The right question is not “what do I do on mount” but “which values does this side effect depend on”. List the dependencies properly and React runs it when it should.

Follow-up: “When does the cleanup function run?” — before the dependencies change and on unmount. Our timer variant question tests exactly this: drop the clearInterval and four start/pause rounds give you 10 seconds instead of 4 (measured).

In one line: props come from the parent and are read-only; state belongs to the component and can change.

Why must props be read-only? Because a render function is supposed to be pure (see #293): the same props render the same UI. Changing props means changing the input, and the parent will overwrite it on its next render — now you have two sources of truth and nobody can say which one to trust.

How to decide which one you need — a practical test:

• You can compute it from props or other state → store neither, just compute it (derived data)
• Only this component cares, and it changes → state
• Several components need it → lift it to their common parent (#345)
• The whole tree reads it and it rarely changes → Context

Follow-up: “Can you put props into state?” — you can, and it is usually a bug: useState(props.value) reads the value on the first render only, so later prop changes never reach the state. Do it only when you need an editable initial value, and think through whether a prop change should reset it. The edit feature in the real Q1 question is that scenario — it syncs explicitly with a useEffect.

In one line: five ways, and you pick by distance — nearest first.

• Parent → child: props.
• Child → parent: the parent passes a callback down as a prop and the child calls it. That is all “events go up” means.
• Between siblings: lift the state to their common parent and pass it back down to each one (#345).
• Across many levels: Context — good for theme, current user, language: values the whole tree reads and that rarely change.
• Global, complex, written from many places: a state library (Redux / Zustand / Jotai) or a server-state library (TanStack Query).

Two less common ones they still ask about: ref plus useImperativeHandle (the parent calls a method on the child, say focus() or play()); and props.children (composition over configuration, which is also one answer to props drilling).

Follow-up: “When should you reach for a state library?” — the test: one piece of state is read and written by many unrelated components, or you need time-travel debugging or middleware. Depth alone is no reason for Redux — Context or composition is enough — that answer beats “big project, use Redux” by a mile.

In one line: controlled = React state owns the value (value + onChange); uncontrolled = the DOM keeps the value and you read it with a ref when you need it.

Default to controlled. The moment you need “disable submit while the field is empty”, a live character count, or two fields that react to each other, controlled is the only comfortable option — the validation requirement in the real Q1 question works exactly that way.

Two real cases for uncontrolled: <input type="file"> (it can only be uncontrolled — for security reasons JS cannot set its value); and performance-sensitive large forms, where every keystroke would otherwise re-render the whole form.

Follow-ups — these come up a lot: “What happens if you pass value but no onChange?” — the input goes read-only, typing does nothing, and React warns you.
“How do you give a controlled component an initial value without locking it?” — defaultValue, but that makes it uncontrolled.
“And value={undefined}?” — React treats it as uncontrolled, then warns you about switching from uncontrolled to controlled once you do pass a value. So the initial value should be "", not undefined.

In one line: when two sibling components need the same data, move the state up to their closest common parent, then pass it down through props and report back through callbacks.

Why does it have to work this way? Because React has one-way data flow — data only travels down, and siblings have no channel between them. The only shared point is a common ancestor.

Three steps: (1) find the closest common parent; (2) move the state up there; (3) have the parent hand the value and the function that changes it to each child.

The cost — bring it up yourself: the higher you lift, the more props the middle layers are forced to pass through (that is props drilling, #331), and a parent re-render drags the whole subtree with it. So the rule is: lift to the lowest layer that works, and no higher.

The real Q1 question is a textbook lift: notes lives in NoteManager (the parent), and both the form and the table are its children; on submit the form calls the callback the parent passed down.

Follow-up: “What if it is lifted too high?” — Context, composition (children), or a state library. Note that Context solves delivery, not sharing — you still have to decide where the state belongs.

In one line: to get data down to a deep component, the components in between that have no use for it are forced to pass it along, level by level.

Why that is a problem:

• The middle components get polluted — fields that have nothing to do with them show up in their props signature, so they get less reusable.
• One change touches a whole chain — adding a field means editing every component on the path.
• Extra re-renders — when the value changes, the entire path re-renders.

Four fixes, cheapest first:

1. Composition / children — the most underrated one. Pass elements down as props and the middle layers never need to know what data they want.
2. Context — good for theme, user, language: values the whole tree reads and that rarely change. Our theme-switching variant question is this one.
3. A state library — for complex global state.
4. Re-splitting the component tree — sometimes drilling is just a symptom of a bad split.

Follow-up: “Do two or three levels need Context?” — no. Two or three levels of props are clear and easy to trace; Context makes “where did this value come from” invisible, and every consumer re-renders when the context changes. It pays off once drilling passes three or four levels and the middle layers are completely unrelated.

In one line: React.PureComponent ships with a shallow-comparison shouldComponentUpdate — if a shallow compare of props and state finds nothing changed, it skips the render. The function-component equivalent is React.memo.

The shallow compare is the whole point of this question. It runs Object.is on each prop, one level deep. So:

• Pass an object, array or function literal and the optimisation is dead, because every render creates a new reference.
• Mutate something deep inside an object and it will not re-render, because the reference never changed — and the UI just stops updating.

So PureComponent / memo and immutable updates come as a pair: you have to build a new object every time for the shallow compare to see a change. The reverse holds too — mutate in place and adding memo manufactures bugs.

Follow-up: “How do you make memo actually work?” — stabilise the references: useMemo for objects and arrays, useCallback for functions. The three go together; memo on its own often does nothing at all (see #346).
“Should every component be memoised?” — no. The shallow compare costs something too, so a component with many frequently changing props gets slower, not faster.

In one line: a container that produces no real DOM node, so you can satisfy “JSX needs a single root” without pushing another div into the page.

Two forms: <React.Fragment> and the shorthand <></>.

Why you need it — you only answer this well with concrete cases:

• Tables — a div inside a <tr> is invalid HTML; the browser hoists it out and the layout breaks on the spot.
• Flex / Grid layouts — an extra div breaks the direct relationship between the container and its items, so every flex property stops working.
• Fewer DOM levels, and easier style selectors.

Follow-up: “Can a Fragment take a key?” — yes, but only in the long form <React.Fragment key={id}>; the shorthand <> accepts no attributes at all. You need this whenever a list renders several sibling elements per item, and it is the shorthand’s only limitation.

In one line: a higher-order component — a function that takes a component and returns an enhanced one. It is the old answer to reusing component logic.

withRouter, connect (Redux) and withStyles are all HOCs. It is nothing more than the higher-order function from #292 applied to components.

Three things you must get right — the marks are here:

• Forward the props — <Comp {...props} />, or you swallow the ones the component already had.
• Copy the statics — wrapping loses the original component’s static properties (hoist-non-react-statics exists for this).
• Refs do not pass through — you need forwardRef.

Why it fell out of favour — this is the real point:

• Wrapper hell — stack three or four and DevTools is nothing but nesting; debugging hurts.
• Props of unknown origin — a user prop shows up in the component and you cannot tell which HOC injected it.
• Name collisions — two HOCs both injecting data fight each other.

Custom hooks fix all three: they stay flat, the origin is explicit (const user = useUser() says it out loud), and you choose the name. So hooks come first now.

Follow-up: “Is there still a use for HOCs?” — two places hooks cannot cover: when you need to wrap the rendered output (putting an error boundary or a layout around every page), and when you have to rewrite props before handing them to a component you cannot modify.

In one line: hooks are functions that start with use and give function components state and side effects.

They fix three real pain points — these three are the standard answer:

• Reusing logic was hard. All you had were HOCs and render props, and both leave you with wrapper nesting (see #335). A custom hook is flat.
• Logic got chopped up by the lifecycle. One coherent “subscribe and unsubscribe” had to be split across two lifecycle methods; useEffect keeps them side by side.
• this was too easy to get wrong. Function components have no this.

The common ones: useState, useEffect, useContext, useRef, useMemo, useCallback, useReducer; React 18 added useId, useTransition, useDeferredValue and useSyncExternalStore.

Two rules — always say them:

1. Call them at the top level only — never inside an if, a loop, or a nested function.
2. Call them only from a function component or a custom hook.

Why the first rule exists — that is the follow-up. React does not know what your hook is called. It keeps each hook’s state in a linked list, indexed by call order. Put a hook inside an if, skip it on one render, and every index after it shifts — useState hands you somebody else’s value.
Say “by call order, not by name” and they know you really understand it.

In one line: useMemo caches “what a function returns”, useCallback caches “the function itself”. Both use the dependency array to decide whether to recompute.

In fact useCallback(fn, deps) is exactly the same thing as useMemo(() => fn, deps) — the former is sugar for the latter. Saying this scores points.

When not to use them — most people miss this half: both cost something — the old value is kept and the dependencies get compared. Wrapping a + b in useMemo is a pure loss. “Measure first, then optimise”: leave them out by default and add them when the profiler says so.

The most common misuse: wrapping something in useCallback but putting a value that changes every render in the dependency array — the cache never hits, and you paid for the comparison on top.

Follow-up: “What changes with the React 19 compiler?” — React Compiler can insert memoisation for you, so most hand-written useMemo and useCallback will stop being necessary. Knowing the direction shows you are keeping up.

In one line: React.memo works at the “component” level — it decides whether to re-render a whole component; useMemo works at the “value” level — it decides whether to recompute one value.

The key point: all three go together. Dropping React.memo on a child usually does nothing at all — the parent hands down fresh object and function literals on every render, so the shallow compare is bound to say “changed”. You must also stabilise objects with useMemo and functions with useCallback.

Follow-up: “Can memo stop a context change?” — no it cannot. memo only compares props; context travels a separate channel. That is why a context value has to be wrapped in useMemo — exactly the point of our theme switching variant, where deleting the useMemo left every behaviour test green and only the reference-stability test red.
“Does children break memo?” — yes. children is a prop too, and JSX produces a new element object every time.