React & Next.js

A state update schedules a re-render. React calls your component function again, producing a new element tree, and diffs it against the previous one. The diff is heuristic, not optimal — a general tree diff is O(n³), so React makes two assumptions to get O(n):

1. Two elements of different types produce different trees, so it unmounts the old subtree and mounts a new one rather than trying to match across types.
2. Siblings are matched by key.

Then it commits the minimal set of DOM mutations. The crucial sentence: a re-render is not a DOM update. Components re-render constantly; the DOM only changes where the diff found a difference. Candidates who conflate the two end up memoising things that were never touching the DOM anyway.

If they push into Fiber: rendering is split into a render phase (interruptible, can be thrown away, must be pure — this is why Strict Mode double-invokes in development) and a commit phase (synchronous, applies the mutations, runs layout effects). That split is what makes concurrent features possible.

Keys tell React which element in the new list corresponds to which in the old. With array indices as keys, deleting the first item shifts every subsequent key down by one — so React concludes that every item's content changed, rather than that one item was removed.

What actually breaks is anything not in props: uncontrolled input values, focus, scroll position inside the row, CSS transitions, and component-local state. They follow the position instead of the data.

// delete row 0 and the typed values shift up by one
{rows.map((r, i) => <input key={i} defaultValue={r.name} />)}

// stable identity — state follows the row it belongs to
{rows.map(r => <input key={r.id} defaultValue={r.name} />)}

Index keys are safe for a list that is never reordered, filtered, sorted or spliced — an append-only log, for instance. Say that qualification; a blanket "never use index keys" sounds memorised.

The inverse trick worth knowing: you can deliberately change a key to force a remount and reset state — <Form key={userId} /> is the idiomatic way to clear a form when the selected user changes.

Classically, all three help in exactly three situations: an expensive computation on every render; a value or callback passed to a memoised child, where a fresh identity would defeat the memo; and a value in a dependency array, where a new identity would re-fire an effect. Everywhere else they cost more than they save — each adds a comparison and holds a reference alive.

It runs after the render is committed to the DOM. The dependency array controls re-running; the returned function runs before the next run and on unmount.

Bug one: the stale closure. The effect captures state from the render it was created in and then reads that stale value later — classically inside a setInterval.

useEffect(() => {
  const id = setInterval(() => setCount(count + 1), 1000)
  return () => clearInterval(id)
}, [])                          // count is frozen at its first-render value

// functional updater — no dependency on the current value at all
setCount(c => c + 1)

// or a ref holding the latest value, when you need to READ it
const latest = useRef(count)
useEffect(() => { latest.current = count })

useEffect(() => {
  const ac = new AbortController()
  fetch(`/api/users/${id}`, { signal: ac.signal })
    .then(r => r.json()).then(setUser)
    .catch(e => { if (e.name !== 'AbortError') setError(e) })
  return () => ac.abort()        // stale request cancelled on id change
}, [id])

Bug two: no cleanup. A subscription or an in-flight request that outlives the component — a resolved response calls setState after unmount, or a slower earlier request overwrites a faster later one (the race that shows the wrong user's data).

That answer wins because it names the losses. A candidate who claims a migration had no downside gets marked down every time — the interviewer's job is to find out whether you evaluate or evangelise.

Be ready for the technical follow-up on why Zustand re-renders less than Context: it uses an external store with selector-based subscriptions (useSyncExternalStore underneath), so a component re-renders only when the slice it selected changes. Context has no selector — every consumer re-renders when the value changes.

Context solves prop drilling — it is dependency injection for the tree. It does not solve rendering: every consumer re-renders when the provider's value changes, with no way to subscribe to a slice of it. Put a frequently-changing object near the root and you re-render half the application.

Three mitigations, in order of preference:

1. Split into several contexts by change frequency — a rarely-changing ThemeContext and a frequently-changing CartContext should not be one object.
2. Memoise the provider value, otherwise a new object literal every render invalidates every consumer regardless.
3. For genuinely shared mutable state, use an external store with selectors — which is the actual argument for Zustand in your migration story.

// every consumer re-renders on every parent render — new object each time
<Ctx.Provider value={{ user, setUser }}>

// stable identity
const value = useMemo(() => ({ user, setUser }), [user])
<Ctx.Provider value={value}>

Controlled: React state is the source of truth, every keystroke is a render. Uncontrolled: the DOM holds the value and you read it via a ref on submit.

Controlled for live validation, dependent fields, and input formatting. Uncontrolled for large forms where per-keystroke renders cost you — which is exactly why React Hook Form is uncontrolled underneath and outperforms Formik on big forms. Naming that connection is the answer.

// controlled — re-renders the form on every keypress
<input value={v} onChange={e => setV(e.target.value)} />

// uncontrolled — zero renders while typing
<input defaultValue={v} ref={ref} />

There are four layers, and knowing there are four is most of the answer:

1. Request memoisation — dedupes identical fetch calls within a single render pass, so three components asking for the same user cause one request. For non-fetch data access, React's cache() does the same.
2. Data Cache — persistent across requests and deploys, controlled per fetch.
3. Full Route Cache — the rendered HTML and RSC payload for static routes.
4. Router Cache — client-side, holds visited segments for back/forward navigation.

// not cached (the default since 15)
await fetch(url)

// cached until revalidated
await fetch(url, { cache: 'force-cache' })

// time-based
await fetch(url, { next: { revalidate: 3600, tags: ['products'] } })

// non-fetch data (an ORM query)
const getUser = cache(async (id) => db.user.findUnique({ where: { id } }))

'use cache'
import { cacheLife, cacheTag } from 'next/cache'

export async function getProducts() {
  'use cache'
  cacheLife('hours')
  cacheTag('products')
  return db.product.findMany()
}

// invalidate after a write, from a Server Action or route handler
revalidateTag('products')

They run only on the server, never ship their code to the browser, and can await data directly. That means: no useState, no useEffect, no event handlers, no browser APIs, no class components.

The model: server components are the default; push 'use client' as far down the tree as you can, so interactivity is a set of islands rather than the whole page. A 'use client' at the top of a layout drags everything below it into the client bundle, which is the most common way teams accidentally lose the entire benefit.

Two gotchas worth naming unprompted:

• Props crossing the server→client boundary must be serialisable — no functions, no class instances, no Dates in older versions. This is the error people hit first.
• A client component can render a server component, as long as it arrives as children rather than being imported. That is the escape hatch for wrapping server content in a client provider.

// this does NOT pull Feed into the client bundle
<ClientProvider>
  <ServerFeed />      // passed as children from a server parent
</ClientProvider>

// this DOES — an import inside a client file is a client import
'use client'
import ServerFeed from './server-feed'   // no longer a server component

A Server Action is a function marked 'use server' that runs on the server but can be called directly from client code or wired to a <form action>. Next creates the endpoint for you; you never write the fetch, the route or the serialisation.

The genuinely useful property is progressive enhancement: a form with a server action submits and works before JavaScript has loaded, because it is still an HTML form post.

// app/actions.ts
'use server'
export async function createBooking(prev, formData) {
  const parsed = BookingSchema.safeParse(Object.fromEntries(formData))
  if (!parsed.success) return { error: 'Check the dates' }
  await db.booking.create({ data: parsed.data })
  revalidateTag('bookings')
  return { ok: true }
}

// the form — React 19 hooks
'use client'
const [state, action, pending] = useActionState(createBooking, null)
return (
  <form action={action}>
    <input name="date" />
    <button disabled={pending}>{pending ? 'Booking…' : 'Book'}</button>
    {state?.error && <p role="alert">{state.error}</p>}
  </form>
)

• Actions and useActionState — pending state, errors and optimistic updates for async mutations, without hand-rolled isLoading booleans.
• useOptimistic — show the result immediately, reconcile when the server answers, roll back on failure.
• useFormStatus — a nested button can read its parent form's pending state without prop drilling.
• use() — read a promise or a context conditionally, unlike a hook. Lets you unwrap a promise passed down from a server component.
• ref as a prop — forwardRef is no longer needed for function components. Large amounts of boilerplate deleted.
• <Context> as a provider — <Ctx> instead of <Ctx.Provider>.
• Document metadata and resource hints — <title>, <meta>, preload hoisted automatically from anywhere in the tree.
• Better error messages for hydration mismatches — a genuine day-to-day improvement.

const [optimistic, addOptimistic] = useOptimistic(
  messages,
  (state, newMsg) => [...state, { ...newMsg, sending: true }]
)

async function send(formData) {
  const text = formData.get('text')
  addOptimistic({ text })        // paints instantly
  await sendMessage(text)        // reverts automatically if this throws
}

The server sends HTML; React then attaches event listeners and builds its internal tree over that existing markup rather than recreating it. A mismatch is when the tree React builds on the client differs from the HTML the server sent.

The causes, in the order you will actually meet them:

• Date.now(), new Date() formatting, Math.random() — different value on each side.
• Reading window, localStorage, navigator or a media query during render.
• Locale or timezone differences between server and browser.
• Invalid HTML nesting — a <div> inside a <p>, which the browser silently restructures so the DOM no longer matches what React sent.
• Browser extensions injecting attributes.

const [mounted, setMounted] = useState(false)
useEffect(() => setMounted(true), [])
if (!mounted) return <Skeleton />      // server and first client render agree
return <LocalTime value={ts} />

// or, for a single unavoidable node:
<time suppressHydrationWarning>{new Date().toLocaleString()}</time>

Answer in four beats — measured, diagnosed, changed, verified:

• Measured. Name the metric and the tool. Lighthouse LCP on the three heaviest routes, plus server-side p95 on the endpoints those routes call. Give the before number if you have it.
• Diagnosed. The heavy routes made the same expensive read on every request — listing and category data that changed a few times a day. The database was repeating identical work.
• Changed. Redis cache-aside in front of those endpoints, plus the Redux→Zustand move which cut the JavaScript the client had to parse before hydration.
• Verified. Same Lighthouse runs, same routes, plus cache hit ratio from Redis INFO.

Volunteering that limitation makes every other number on your resume more credible, not less. Interviewers are calibrating how much of what you say they can trust; a candidate who marks their own uncertainty gets trusted on everything else.

Fixes worth naming: next/image with explicit sizing (it reserves the box, which is most of CLS), font-display: swap with a metric-matched fallback, preloading the LCP image, and code-splitting to shorten long tasks.

• Rules of hooks and why. Hooks are matched by call order across renders; a conditional hook desynchronises the list and state lands on the wrong hook.
• useRef vs useState. Both persist across renders; only state triggers one. Refs for DOM nodes, timer ids, and "latest value" reads.
• useLayoutEffect. Runs synchronously after DOM mutation, before paint. For measuring an element and adjusting it without a visible flicker. It blocks paint, so use it sparingly — and it does not run on the server.
• Custom hooks. A function starting with use that calls other hooks. A good one has a single responsibility and returns a stable API.
• React.lazy + Suspense. Split at route boundaries first, then at heavy below-the-fold components (a chart library, a rich text editor).
• Error boundaries. Catch errors during rendering, in lifecycles and in constructors. They cannot catch errors in event handlers, async code, or on the server during SSR — those need try/catch.
• Virtualising 50,000 rows. Render only the visible window plus an overscan buffer; react-window or TanStack Virtual. The hard part is variable row heights.
• useTransition. Marks an update as non-urgent so typing stays responsive while an expensive list re-filters. useDeferredValue is the value-shaped version.
• Middleware in Next. Runs before a request completes, at the edge. Auth redirects, locale routing, A/B bucketing. Keep it thin — it is on every request.
• Route handlers. app/api/x/route.ts exporting GET/POST. They take and return standard Web Request/Response, unlike the old req/res API routes.
• Auth in the App Router. Session check in a server component or middleware; never trust a client-side guard, because the data fetch is what actually needs protecting.
• loading.tsx and error.tsx. File conventions that wrap a segment in Suspense and an error boundary automatically.
• Parallel and intercepting routes. Slot-based layouts and the "open a photo in a modal but deep-link to the full page" pattern.
• How do you test a component? React Testing Library, asserting on what a user sees and does — roles and text, not class names. Do not test implementation details or internal state.
• WCAG 2.1 AA — name four things you actually did. Semantic landmarks and heading order; focus management on route change; contrast ratios of 4.5:1 for text; labels on every control with ARIA only where semantics ran out; no keyboard traps in modals.