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

In one line: a single-page application — one HTML document gets loaded, and from then on JS swaps the content on the client instead of asking the server for a whole new page.

Upsides: no white flash when you change pages, it feels close to a native app, and front end and back end are fully separated (the server only returns JSON).

Costs — this is the half they probe:

• Slow first paint — you have to download and run a big JS bundle before anything shows up. The fixes are code splitting (React.lazy, see #347) and SSR.
• Weak SEO — a crawler receives an empty<div id="root"></div>. The fix is SSR / SSG (Next.js).
• You own the routing — back and forward, deep links, staying on the current page after a refresh, all of it rides on the history API plus a fallback on the server. “404 on refresh” means the fallback is missing.
• Memory leaks — the page never reloads, so timers and listeners are never cleared for you. That is the practical reason useEffect needs a cleanup function.

Follow-up: “When is an MPA better?” — content sites (blogs, docs, product detail pages) where SEO and first paint matter and the interaction stays simple. “It depends on the case” beats praising SPAs unconditionally.

In one line: declarative + component-based + one-way data flow — you describe what the UI should look like and React makes the DOM match.

• Declarative — you write {items.map(...)}, not “find the ul, create an li, appendChild”. What you drop is the step-by-step code for getting from state A to state B, and that is where most bugs live.
• Components — the UI splits into reusable units you can test on their own.
• One-way data flow — props go down, events go up. When something breaks, there is exactly one path to trace: the data can only have come from one direction.
• Ecosystem — Router, state libraries, Next.js, React Native (the same mental model gets you a mobile app).

They will ask for the downsides (have them ready): it is only a view library, so you pick the router and the state layer yourself — the cost of those decisions is real; performance work is manual (memo / useMemo; there was no automatic memoization before React 19); JSX and the hook rules are a hurdle for beginners; and version migrations carry a lot of mental load (class → hooks → Server Components).

In one line: React is a library (it handles the view, you choose the rest); Angular is a framework (routing, HTTP, forms, dependency injection and testing all come in the box).

How to answer without picking a fight: do not talk one down to lift the other. Say “React gives you freedom and the burden of choosing; Angular gives you conventions and a learning cost. The answer differs for a small fast project and for a big one many people maintain for years.”

They will ask about Vue — Vue sits between the two: it has an official router and state library (more unified than React) but stays lighter than Angular, and the template syntax is quick to pick up.

In one line: a syntax extension for JavaScript that lets you write HTML-like structure inside JS. The browser does not understand it — Babel compiles it into plain function calls.

What it compiles to (this is the part being tested): old versions produced React.createElement(type, props, ...children); since React 17 the new JSX transform emits _jsx(...), which is why you no longer have to write import React by hand.

The rules you should state clearly:

• One root node is required — a function can only return one value. If you do not want another div, use a Fragment (see #338).
• Attribute names are camelCase — className (because class is a JS keyword), htmlFor, onClick.
• {} holds an expression, not a statement — so conditional rendering uses a ternary or &&, never if.
• JSX escapes by default, so you get XSS protection for free; injecting raw HTML takes an explicit dangerouslySetInnerHTML — the name is deliberately ugly so that you stop and think.

Follow-up: “Is JSX mandatory?” — no, you can call createElement yourself, nobody wants to. The value of JSX is that UI structure looks like structure in the code.

In one line: the virtual DOM is a lightweight tree of plain JS objects describing the real DOM. When state changes, React builds a new tree in memory, diffs it against the old one, works out the smallest set of changes, and applies them to the real DOM in one go.

Why it is fast — get these two right:

• Batching — ten state updates collapse into one DOM write, so you avoid ten reflows (see #288).
• Minimising — only the attributes and nodes that really changed get touched; whole subtrees are not rebuilt.

But say this part too — it is the bonus point: the virtual DOM is not necessarily faster than hand-written DOM code — carefully tuned native operations always win, and the virtual DOM pays extra for building a tree and diffing it. Its real value is that you keep the declarative style and performance is still good enough — it is a trade-off between maintainability and performance. It is not the right choice everywhere.

The three diff heuristics (what turns O(n³) into O(n)):

1. Compare the same level only; nodes never move across levels. Crossing a level means delete and rebuild.
2. A different type rebuilds the whole subtree — swap a div for a span and the subtree is thrown away and redone, state included.
3. Lists on the same level use key for identity.

Why index must not be the key — the most useful thing you can say in a React interview: insert or delete at the front and every index shifts, so React believes the content of every row changed and does a pile of needless updates; worse, text typed into an uncontrolled input ends up on the wrong row, because the DOM node got reused. The delete-a-note bug in the real Q1 question is exactly this.

In one line: reconciliation is the whole process of comparing the new and old virtual DOM trees and deciding which operations to run on the real DOM. The diff algorithm is one part of it.

How do diff and reconciliation relate? That is the point of the question: diff is the algorithm for how to compare; reconciliation is the full compare, decide and commit flow. Calling them the same thing is not wrong, but telling them apart is better.

The Fiber architecture, from React 16 on, splits the process into two phases — answer this every time:

• Render phase (interruptible) — build the Fiber tree, diff, mark what has to change. This phase can be paused and resumed, which is how a high-priority update such as typing jumps the queue.
• Commit phase (not interruptible) — apply the marked changes to the real DOM in one pass, then run useEffect. This part must finish synchronously, otherwise users would see a half-rendered screen.

Why does it need to be interruptible? Because the old Stack Reconciler was recursive and could not stop once it started, so a large list update blocked the main thread for tens of milliseconds and typing stuttered. Fiber replaces recursion with a linked list plus a loop, and after each small chunk it checks whether something more urgent came in. This is the foundation of the concurrent features (see #344).

Follow-up: “Why does StrictMode render twice?” — because the render phase can be interrupted and re-run, so the render function has to be pure; the double render is there to expose the impure parts (see #332).

The split in one line: Babel translates (JSX and new syntax → JS the browser understands); Webpack bundles (a pile of modules and assets become the few files you ship).

• Babel — @babel/preset-react handles JSX, @babel/preset-env down-levels ES2020+ for your target browsers. It only transforms syntax; new APIs (Promise, Array.flat) still need a polyfill. Drawing that line scores points.
• Webpack — reads your imports to build a dependency graph, lets you import CSS and images too, does tree shaking and code splitting, and gives you a dev server with hot reload while you work.

The order: when Webpack hits a .jsx file it calls babel-loader, so Babel is one stage of the Webpack pipeline.

Follow-up: “Are they still used?” — knowing the current state is what shows you keep up: new projects mostly reach for Vite (native ESM plus esbuild in development, Rollup for production), and Babel is often replaced by esbuild or SWC — an order of magnitude faster. Webpack is still everywhere in existing codebases and wherever heavy customisation is needed.
The React source project in this course uses Vite — which is why there is no webpack in its node_modules at all.

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.