性能与新特性 · 八问8 questions on performance and new features

Open with this sentence, then list the techniques: “First I use the React DevTools Profiler to find which component is slow and how many times it renders, then I decide what to touch.” Reciting useMemo straight away sounds like you memorised an answer sheet.

Three families of technique:

① Render less

• React.memo + useMemo + useCallback used as a set (#346)
• Push state down — put frequently changing state in the small component that actually needs it instead of lifting it to the top and re-rendering the whole tree. This often helps far more than adding memo.
• Compose with children — when the parent re-renders, children passed in as a prop are not rebuilt.
• Split your contexts — put too much in one context and changing any field re-renders every consumer.

② Download less

• Code splitting — React.lazy + Suspense, split per route (#347)
• Import third-party libraries piecemeal, not import _ from "lodash"
• Run a bundle analyzer to see who is taking up the space

③ Compute less, paint less

• Virtualise long lists — render only the few dozen rows in the viewport. On a ten-thousand-row list this beats every other optimisation put together.
• Use stable ids as list keys (#330)
• Debounce input, throttle search
• React 18’s useTransition / useDeferredValue — keep the heavy work from blocking typing

Follow-up: “How do you know there are wasted renders?” — the Profiler’s “Highlight updates”, or <Profiler onRender>; and remember StrictMode renders twice in development, so do not mistake that for a bug.

In one line: five ways, each with a clear trade-off.

The recommended way to do dynamic styles — this is the bonus point: use a CSS variable, not an inline style. Put only the variable inline and leave the actual rule in the CSS file — you get the dynamic value and keep pseudo-classes and media queries. That is how this site’s dark mode works (flip the data-theme attribute and the whole set of CSS variables swaps).

Follow-up: “Why do inline styles hurt performance?” — every render creates a new object, which breaks memo on the child, and the browser cannot cache it as a rule. If you must use one, stabilise it with useMemo.

In one line: the core is concurrent rendering — React can interrupt, pause and resume a render so a higher-priority update goes first.

Five concrete changes — covering three or four properly is enough:

• Automatic batching — React 17 only batched inside React event handlers, so several setState calls in a setTimeout, a Promise or a native event each triggered their own render. 18 batches all of them. This is the change you notice most easily.
• useTransition — mark an update as “not urgent”. The classic case is an input next to a heavy list of search results: typing stays smooth and the list catches up.
• useDeferredValue — same goal, from the value side: give me a version of this value that lags behind.
• The new root API — createRoot replaces ReactDOM.render, and until you switch you get none of the concurrent features.
• Suspense works on the server — streaming and selective hydration.
  Plus useId (ids that match between server and client) and useSyncExternalStore (for state libraries).

Follow-up: “What changed for StrictMode in 18?” — it now does an extra mount, unmount, mount, so effect cleanup functions actually run. The point is to expose components that forgot to write cleanup (see #332) and to prepare for the future Offscreen feature.
“What do you watch out for when upgrading?” — switch to createRoot; automatic batching can change the behaviour of old code that assumed “every setState renders right away” (use flushSync to escape a batch when you truly need to).

In one line: it makes a component load on demand — the bundler cuts it into its own chunk, and the chunk is fetched only when you actually render it. It needs a Suspense around it to supply a placeholder.

Why you need it: by default an SPA is one bundle, so the first screen downloads the code for every page (see #321). Splitting per route is the highest-value cut — opening the home page should not download the settings page.

Four things to watch:

• What you pass to lazy must return a Promise with a default export — so it pairs with default export; a named export needs a small wrapper.
• The path in a dynamic import() cannot be a fully dynamic variable — the bundler has to be able to analyse it at build time.
• Handle the failure case — if the network drops the chunk never arrives, so wrap it in an error boundary (see #333). Most people leave this out, so it is a bonus point.
• Do not split too finely — every chunk is another request.

Follow-up: “How do you avoid a loading flash when switching pages?” — preload: call that import() once when the mouse hovers the link (the module gets cached). Or use React 18’s useTransition to keep the old page on screen until the new one is ready.

In one line: a checking component that only does anything in development, and it exposes unsafe code by deliberately doing things twice. In a production build it does nothing.

It does three things:

• Calls your render function twice — which surfaces side effects during render (mutating an outer variable, mutating props directly). Because the render phase can be interrupted and re-run (see #353), it has to be pure.
• Since React 18: effects run mount, unmount, mount — specifically to expose effects with no cleanup function. If mounting twice breaks your component (a duplicated subscription, a doubled timer), that is a real bug.
• Warns about deprecated APIs and legacy ref patterns.

The most important sentence: a problem caused by double rendering is not StrictMode’s problem, it is your code’s. Most people’s first instinct is to turn it off — the right instinct is to fix the side effect.

Follow-up: “Is it normal for my log to print twice?” — yes in development, because the render function ran twice; it will not in production.
“What about my request firing twice?” — take that one seriously: it means your effect is not cleaning up properly. Harmless for an idempotent GET, but it is also telling you to ask whether you guarded against races. The ignore flag plus abort pattern from our fetch variant is exactly what makes it behave correctly under StrictMode too.

In one line: a class component that catches render errors in its subtree and renders a fallback UI instead of letting the whole app go blank.

How you write one: implement getDerivedStateFromError (to switch to the fallback) and componentDidCatch (to report the error). It still has to be a class component — there is no hook equivalent.

What it does not catch — this is the real question:

• Errors inside event handlers — those do not happen during render. Use your own try/catch.
• Errors in async code — setTimeout, Promise callbacks (the same reason as #310).
• Server-side rendering.
• Errors thrown by the boundary itself.

Where to put them: get the granularity right. One at the root only means a single broken widget still wipes out the page; put one around each independent block — each route, and each widget that can fail on its own (sidebar, chart, comments). Then one broken block leaves the rest usable.

Follow-up: “How does the user recover?” — give the fallback a “Retry” button that resets the boundary’s state (or changes a key to force the subtree to rebuild). The react-error-boundary library gives you resetErrorBoundary for this.

In one line: it gives an SPA the concept of a URL — it maps the address bar to whichever component is rendered, and switches between them without a page reload.

It solves four things:

• Mapping URLs to components
• Back and forward work — it takes over the history API
• Deep links are shareable — send one to someone and it opens that page directly
• Nested routes — the layout layer and the content layer stay separate (Outlet)

The core API: BrowserRouter, Routes / Route, Link / NavLink, useNavigate, useParams, useSearchParams, Outlet.

Three practical points:

• Use Link, not <a> — an anchor really does reload the whole page, which throws away the point of an SPA.
• BrowserRouter needs the server to fall back to index.html for every path, otherwise refreshing a nested route 404s. If you cannot configure the server, use HashRouter. This one comes up a lot.
• Pair it with React.lazy to split code per route (#347).

Follow-up: “How do you do route guards?” — React Router has none built in; you write a wrapper component yourself: if the user is not signed in, render <Navigate to="/login" />.

This is an open question, and a list with trade-offs beats a pile of rules. Six, most important first:

• Update immutably. Always build a new object or array, never edit in place — otherwise React compares references, sees nothing changed, and the UI does not update. This is the single most common source of bugs in React.
• If you can compute it, do not store it in state. Derive it on the spot; do not use useEffect to keep two copies in sync — one fact stored twice will drift.
• Keep state at the lowest level that works. Too high and you get prop drilling and wasted renders; too low and siblings cannot reach it.
• Anything an effect sets up has to be torn down. Timers, listeners, subscriptions, in-flight requests. The test: if the effect contains setInterval, addEventListener, subscribe or fetch, it must return something.
• Use stable business ids as list keys, not the index.
• Measure before optimising. Do not wrap everything in useMemo by default.

Two more on the engineering side: keep components small and single-purpose (one component, one job); and use TypeScript — the shape of the props is the component’s contract, and writing it down beats remembering it.

If the interviewer wants something more specific, you can say: “I keep eslint-plugin-react-hooks on and I do not silence the exhaustive-deps warning with a comment — it is right almost every time, and wanting to get around it usually means the code needs restructuring.” That one really shows hands-on experience.