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.