Concurrent Rendering (React 18) Interview Questions

startTransition — marking low-priority renders

// Without startTransition — input lags because filter render blocks it
function SearchPage() {
  const [query, setQuery] = useState('')
  const [results, setResults] = useState(allItems)
  function handleChange(e) {
    setQuery(e.target.value)        // urgent — input must update immediately
    setResults(filter(allItems, e.target.value))  // expensive — but treated equally urgent
    // React renders BOTH synchronously — input update waits for filter to complete
    // Result: input lags by however long filter takes (e.g. 200ms)
  }
  return (
    <>
      <input value={query} onChange={handleChange} />
      <ResultList items={results} />
    </>
  )
}
// With startTransition — input is instant, results trail slightly
function SearchPage() {
  const [query, setQuery] = useState('')
  const [results, setResults] = useState(allItems)
  function handleChange(e) {
    setQuery(e.target.value)        // urgent — SyncLane — renders immediately
    startTransition(() => {
      // This update is TransitionLane — low priority
      // React will render this only when the main thread is free
      // If another keystroke arrives, this render is abandoned and restarted
      setResults(filter(allItems, e.target.value))
    })
  }
  return (
    <>
      <input value={query} onChange={handleChange} />
      <ResultList items={results} />  {/* may show stale results briefly — that's ok */}
    </>
  )
}
// useTransition — same idea, plus isPending flag
function SearchPage() {
  const [query, setQuery] = useState('')
  const [results, setResults] = useState(allItems)
  const [isPending, startTransition] = useTransition()
  function handleChange(e) {
    setQuery(e.target.value)
    startTransition(() => {
      setResults(filter(allItems, e.target.value))
    })
  }
  return (
    <>
      <input value={query} onChange={handleChange} />
      {isPending && <Spinner />}   {/* show loading indicator while transition runs */}
      <ResultList items={results} />
    </>
  )
}

What actually gets aborted — and what never commits

// The guarantee React makes:
// Any render that gets interrupted NEVER commits to the DOM.
// The user ALWAYS sees either the old complete UI or the new complete UI.
// They never see a partial render.
// Timeline with rapid typing "abc":
// t=0: type 'a' → setQuery('a') + startTransition(→ setResults(filter('a')))
// t=0: query renders immediately (input shows 'a')
// t=0: React begins TransitionLane render for results
// t=5ms: type 'b' → setQuery('ab') + startTransition(→ setResults(filter('ab')))
// t=5ms: React ABORTS the 'a' transition render — it will never commit
// t=5ms: query renders immediately (input shows 'ab')
// t=5ms: React begins TransitionLane render for filter('ab')
// t=8ms: type 'c' → same thing — 'ab' transition aborts
// t=8ms: React begins TransitionLane render for filter('abc')
// t=20ms: no more keystrokes — transition completes and commits
// Result: Results show filter('abc'). User never saw filter('a') or filter('ab') results.
// This "latest wins" behavior is the whole point.
// You never need to debounce a startTransition — React handles it.

useDeferredValue — the stale-while-rerendering model

// useDeferredValue is for when you can't wrap the setState in startTransition —
// e.g. the state update happens in a library you don't control, or comes from a URL param.
function SearchResults({ query }) {
  // deferredQuery "lags behind" query intentionally
  // During a fast-changing query, deferredQuery stays on the last committed value
  // while React works on the transition render for the new value
  const deferredQuery = useDeferredValue(query)
  // This expensive component renders with the deferred (possibly stale) value
  // while the urgent component (the input) renders with the current value
  return <ExpensiveList filter={deferredQuery} />
}
function App() {
  const [query, setQuery] = useState('')
  return (
    <>
      {/* This updates immediately — urgent */}
      <input value={query} onChange={e => setQuery(e.target.value)} />
      {/* This may show stale query while new render is in progress */}
      <SearchResults query={query} />
    </>
  )
}
// CRITICAL: useDeferredValue is NOT debounce
// Debounce: delay the update by a fixed time (e.g. 300ms). Timer-based.
// useDeferredValue: show the previous value while React renders the new one.
//   No timer — it defers until React is ready.
//   If the machine is fast, the deferred value updates instantly.
//   If the machine is slow (or the render is expensive), it lags by the render duration.
//   If the render is abandoned (new value arrives), the deferred value doesn't update at all.
// To show "stale" visual signal:
function SearchResults({ query }) {
  const deferredQuery = useDeferredValue(query)
  const isStale = query !== deferredQuery  // true while transition is running
  return (
    <div style={{ opacity: isStale ? 0.5 : 1, transition: 'opacity 0.2s' }}>
      <ExpensiveList filter={deferredQuery} />
    </div>
  )
}

Automatic batching — before vs after React 18

// BEFORE React 18 — batching only inside React event handlers
function handleClick() {
  setA(1)   // batched ↓
  setB(2)   // batched ↓  → 1 render
}
function handleClick() {
  setTimeout(() => {
    setA(1)   // NOT batched — 1 render
    setB(2)   // NOT batched — 1 render
    // Total: 2 renders!
  }, 0)
}
async function handleClick() {
  await fetch('/api/data')
  setA(1)   // NOT batched — 1 render
  setB(2)   // NOT batched — 1 render
  // Total: 2 renders!
}
// AFTER React 18 — batching everywhere, always
// Requires: ReactDOM.createRoot() (not ReactDOM.render())
function handleClick() {
  setTimeout(() => {
    setA(1)   // batched ↓
    setB(2)   // batched ↓  → 1 render ✓
  }, 0)
}
async function handleClick() {
  await fetch('/api/data')
  setA(1)   // batched ↓
  setB(2)   // batched ↓  → 1 render ✓
}
// Native event handlers also get batching:
document.addEventListener('click', () => {
  setA(1)   // batched ↓
  setB(2)   // batched ↓  → 1 render ✓ (was 2 renders in React 17)
})

flushSync — opting out of batching

import { flushSync } from 'react-dom'
// flushSync forces React to flush state updates synchronously and immediately.
// Use it when you need the DOM to update before the next line of code runs.
// Use case 1: Reading DOM measurements after a state update
function handleAdd() {
  flushSync(() => {
    setItems(prev => [...prev, newItem])  // DOM updates before flushSync returns
  })
  // DOM is now updated — safe to read measurements
  listRef.current.scrollTop = listRef.current.scrollHeight  // scroll to new item
}
// Without flushSync: setItems batches → DOM hasn't updated yet → scroll target is wrong.
// The ref still points to the old scroll height.
// Use case 2: Third-party animations that need DOM to be current
function handleTransition() {
  flushSync(() => {
    setVisible(true)   // React commits synchronously
  })
  // DOM now has the element — third-party animation library can find it
  animationLibrary.animate(elementRef.current, { from: 0, to: 1 })
}
// When NOT to use flushSync:
// Almost never. It bypasses batching and Concurrent Mode optimizations.
// It blocks the main thread until the update commits.
// If you find yourself using it often, you probably have an architectural problem.
// Prefer useLayoutEffect for DOM reads after renders — it's the idiomatic solution.

The atomic commit guarantee — what React always preserves

// React's absolute guarantee:
// The DOM is ALWAYS updated atomically — all changes from one render commit together.
// The user never sees a partial UI from a single state update.
// This holds even with:
// - startTransition (transition renders may be abandoned, but if they commit, they commit fully)
// - Automatic batching (all batched updates commit in one pass)
// - Error boundaries (if rendering throws, React rolls back to the nearest error boundary)
// - Suspense (React holds a loading state until ALL suspended children resolve)
// Suspense + atomic commit example:
function ProfilePage() {
  return (
    <Suspense fallback={<Spinner />}>
      <Avatar />       {/* suspends on user data */}
      <Bio />          {/* suspends on user data */}
      <PostList />     {/* suspends on posts data */}
    </Suspense>
  )
}
// React won't commit the new UI until ALL three components are ready.
// The user sees: Spinner → (Avatar + Bio + PostList all at once)
// They never see: Avatar → Bio → PostList appearing one by one.
// This is atomic commit at work.
// The one exception: Suspense with startTransition
// If the transition includes a Suspense boundary, React shows the fallback
// only if the render takes too long (configurable timeout).
// Otherwise it shows the previous UI until the new one is ready.
// This is called "concurrent Suspense" and is how React avoids spinner flashing.