组件与通信 · 十一问11 questions on components and how they communicate

In one line: write function components, always. Class components are for maintaining old code and for error boundaries, which still have to be classes.

Why the official line favours function components — these three points land better than the table:

• Logic groups by concern instead of being sliced up by lifecycle. In a class, subscribing and unsubscribing are forced apart into componentDidMount and componentWillUnmount; useEffect lets them sit together.
• Reusing logic needs no nesting. Three stacked HOCs turn into wrapper hell; custom hooks stay flat.
• The this problem disappears completely.

Follow-up: “How do you get shouldComponentUpdate in a function component?” — React.memo, though it compares shallowly by default; pass a second argument when you need your own comparison.

In one line: three phases — mounting, updating, unmounting.

• Mounting: constructor → getDerivedStateFromProps → render → componentDidMount (the DOM exists now, so fetching, subscribing and DOM work all belong here)
• Updating: getDerivedStateFromProps → shouldComponentUpdate (return false to skip the render) → render → getSnapshotBeforeUpdate → componentDidUpdate (setting state here needs a condition, or you get an infinite loop)
• Unmounting: componentWillUnmount (clear timers, detach listeners, cancel requests)
• On error: getDerivedStateFromError + componentDidCatch (error boundaries, see #333)

Know the three that were deprecated: componentWillMount, componentWillReceiveProps, componentWillUpdate. The reason is that Fiber can interrupt and re-run the render phase, so these could fire more than once and any side effect inside them would run twice. Giving that reason earns real credit.

Follow-up: “Why not fetch in componentWillMount?” — besides the reason above, it also runs during SSR, and it does not get the data any sooner: the request is async, so you wait either way.

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.