React 19 Concurrent Features in Production

The React team shipped React 18 with concurrent rendering as an opt-in. React 19 made it the default. If you upgraded without reading the release notes carefully, you may have already hit the consequences — and you may not have traced them back to the right cause.

This is not a tutorial. You can find React tutorials anywhere. This is a field report from production systems that run React 19 at scale, with users, with state, with complex component trees, and with zero tolerance for regressions.

What "Concurrent by Default" Actually Means

In React 18, concurrent mode required explicit opt-in via createRoot. Most production apps were still using legacy mode unless they deliberately migrated. In React 19, createRoot is the only supported entry point. Legacy mode is gone.

The practical consequence is that every render in your application now has the potential to be interrupted. React can pause a render mid-flight, discard it, and restart — if a higher-priority update arrives. For most UI updates, you will never notice. For certain patterns, it is catastrophic.

The Patterns That Break

The most common failure mode is side effects in render. If your component performs a side effect — writes to a ref, increments an external counter, logs to analytics — during the render phase rather than in a useEffect, that side effect may now execute multiple times per visible render. React may render your component twice to detect which output to show (strict mode), or it may render and discard several times before committing.

In practice, the components most at risk are:

• Components that call analytics.track() during render (not in useEffect)
• Components that mutate refs directly in render to synchronize with third-party libraries
• Components that rely on external mutable state (singleton stores) being stable across render passes

None of these are new problems — they were always bugs. But concurrent rendering makes them visible where they were previously invisible because the double-render was effectively serialized to the same paint frame.

The use() Hook — A Genuine Ergonomic Win

React 19 introduces use(), a hook that can be called conditionally and works inside regular components to read the resolved value of a Promise or a Context.

import { use, Suspense } from 'react'

function Article({ articlePromise }: { articlePromise: Promise<Article> }) {
  const article = use(articlePromise)   // suspends until resolved
  return <h1>{article.title}</h1>
}

export default function Page() {
  const promise = fetchArticle(params.slug)  // initiated in parent
  return (
    <Suspense fallback={<Skeleton />}>
      <Article articlePromise={promise} />
    </Suspense>
  )
}

The key property is that the Promise is created in the parent and passed down — not created inside the component. This distinction matters for cache coherence: if you create the Promise inside the component, it is recreated on every render, which means the suspension is reset on every render. You need a stable Promise reference, which typically means creating it at the data-loading level — in a route handler, a Server Component, or a stable hook.

startTransition — Use It Everywhere You Have Non-Urgent Updates

Transitions are the mechanism by which you tell React that an update is non-urgent. React can defer rendering the result while keeping the UI interactive. The canonical use case is search-as-you-type filtering:

import { startTransition, useState } from 'react'

function SearchInput() {
  const [query, setQuery] = useState('')

  function handleChange(e: React.ChangeEvent<HTMLInputElement>) {
    // Urgent: update the input immediately
    const value = e.target.value

    // Non-urgent: filter the result list
    startTransition(() => {
      setQuery(value)
    })
  }

  return <input onChange={handleChange} />
}

In practice, the performance win from startTransition only materializes when the deferred computation is genuinely expensive — hundreds of list items re-rendering, complex canvas operations, heavy virtualized lists. For simple component trees, the overhead of the transition bookkeeping can exceed the benefit.

The heuristic: if your render finishes in under 16ms, startTransition is probably not worth it. Profile first.

The React Compiler — Still Experimental, Already Useful

React 19 ships with an experimental compiler (formerly "React Forget") that automatically memoizes components and hooks, eliminating the need for manual useMemo and useCallback annotations. In production testing, the compiler eliminates the majority of unnecessary re-renders without requiring any code changes.

The catch is that the compiler requires your code to follow the Rules of React strictly. Components that close over mutable external state, that use imperative patterns, or that have non-idempotent render logic will produce incorrect results when compiled. The compiler cannot warn you about this at build time — it can only infer from the code structure.

Before enabling the compiler, run your test suite with strict mode active and look for any test that passes sometimes and fails others — those are the indicators of impure renders that the compiler will make visible.

Static Export Compatibility

For projects using Next.js with output: 'export', React 19's Server Components are not available. Concurrent features are available client-side. The use() hook works when consuming Promises that are created in your client components or data-loading hooks. Suspense boundaries work for lazy-loaded dynamic components.

The constraint is that you cannot use Server Actions (form submissions that invoke server-side functions) because those require a server runtime. Everything must be client-side state, localStorage persistence, or static data loaded at build time.

This is a real architectural constraint. Plan your data loading strategy before adopting React 19's async patterns in a static export context.

Upgrade Path

If you are upgrading from React 18, the steps are:

1. Enable strict mode if you have not already — this will surface impure renders before the upgrade
2. Run npm run build and look for hydration mismatch warnings — these become errors in React 19
3. Audit all console.warn calls that reference "act()" or "concurrent" in your test output
4. Update your test infrastructure — @testing-library/react v14+ is required for React 19
5. Upgrade packages that have React 19 peer dependencies
6. Enable the React compiler on a branch, run your full test suite, compare bundle output

The upgrade is not painful if your codebase was already following the Rules of React. If it was not, the upgrade will expose bugs that have been silently accumulating.

The Bottom Line

React 19 is a genuinely good release. The concurrent features that were theoretically available in React 18 are now practically available in React 19. The developer experience improvements — use(), the compiler, improved error messages — are meaningful. The migration cost is front-loaded in cleaning up existing impurities, not in learning new APIs.

If you are starting a new project, use React 19 from day one. If you are upgrading, invest one sprint in strict-mode cleanup before the upgrade, and you will save yourself three sprints of debugging afterwards.