Ein Kontaktformular in React zu bauen, war lange mehr Arbeit, als es sein müsste. Ein State für die Eingaben, einer für den Ladezustand, einer für Fehlermeldungen, dazu ein Handler, der das Absenden abfängt, die Anfrage schickt und am Ende alles zurücksetzt. Jedes Team hatte dafür sein eigenes Muster oder eine zusätzliche Bibliothek. React 19 nimmt sich genau solcher Alltagsaufgaben an.

Die Version erschien im Dezember 2024 und ist heute in der Reihe 19.x die aktuelle Hauptversion. Sie bringt keine neue Denkweise wie einst die Hooks, sondern füllt Lücken: beim Absenden von Formularen, beim Laden von Daten, beim Umgang mit Refs und Metadaten. Dazu werden Server Components offiziell Teil von React. Was React 18 vorbereitet hat, also Concurrent Rendering, Transitions und Suspense, beschreibt der Rückblick React 18: die wichtigsten Neuerungen im Überblick.

Actions: asynchrone Abläufe ohne eigenen Ladezustand

Der zentrale Begriff von React 19 heißt Action. Gemeint ist eine Funktion, die React innerhalb einer Transition ausführt und die auch asynchron sein darf. React kümmert sich dann selbst um den Ladezustand, um Fehler und um das Zurücksetzen. Transitions, also Updates, die nicht sofort sichtbar sein müssen, kennt React seit Version 18. Neu ist, dass startTransition jetzt eine asynchrone Funktion annimmt.

Am sichtbarsten wird das bei Formularen. Das form-Element akzeptiert in React 19 eine Funktion als action-Prop. Beim Absenden ruft React sie mit den Formulardaten auf und setzt nicht kontrollierte Formularfelder nach erfolgreichem Absenden automatisch zurück.

useActionState: Ergebnis und Ladezustand in einem Hook

Für den typischen Fall, dass eine Action ein Ergebnis zurückgibt, etwa eine Fehlermeldung, gibt es useActionState. Der Hook hieß in frühen Vorabversionen noch useFormState. Er nimmt die eigentliche Funktion und einen Startwert und liefert den aktuellen Zustand, eine Action für das Formular und ein Flag, ob sie gerade läuft:

import { useActionState } from 'react';
import { useFormStatus } from 'react-dom';

type State = { error: string | null; sent: boolean };

async function sendMessage(_prev: State, formData: FormData): Promise<State> {
  const response = await fetch('/api/kontakt', {
    method: 'POST',
    body: formData,
  });
  if (!response.ok) {
    return {
      error: 'Die Nachricht konnte nicht gesendet werden.',
      sent: false,
    };
  }
  return { error: null, sent: true };
}

// useFormStatus liest den Zustand des umgebenden Formulars,
// deshalb muss der Button eine eigene Komponente innerhalb von form sein
function SubmitButton() {
  const { pending } = useFormStatus();
  return (
    <button type="submit" disabled={pending}>
      {pending ? 'Wird gesendet …' : 'Absenden'}
    </button>
  );
}

export function ContactForm() {
  const [state, formAction] = useActionState(sendMessage, {
    error: null,
    sent: false,
  });

  if (state.sent) return <p>Vielen Dank, Ihre Nachricht ist angekommen.</p>;

  return (
    <form action={formAction}>
      <label>
        E-Mail
        <input name="email" type="email" required />
      </label>
      <label>
        Nachricht
        <textarea name="message" required />
      </label>
      {state.error && <p role="alert">{state.error}</p>}
      <SubmitButton />
    </form>
  );
}

Ein Detail sorgt in der Praxis oft für Verwirrung: useFormStatus stammt aus react-dom und funktioniert nur in einer Komponente, die innerhalb des Formulars gerendert wird. Im Formular selbst aufgerufen, liefert der Hook keinen Ladezustand. Das Beispiel trennt den Button deshalb ab.

useOptimistic: sofort anzeigen, später bestätigen

Optimistische Updates zeigen das erwartete Ergebnis an, bevor der Server geantwortet hat. Angenommen, jemand markiert in einer Aufgabenliste einen Eintrag als erledigt: Der Haken erscheint sofort, die Anfrage läuft im Hintergrund. Mit useOptimistic übernimmt React die Buchhaltung. Solange die Action läuft, gilt der optimistische Wert; danach fällt die Anzeige auf den echten Zustand zurück, auch wenn die Anfrage scheitert. Das spart eigene Logik zum Zurückrollen.

use: Promises und Kontext beim Rendern lesen

Die neue API use liest den Wert eines Promise oder eines Kontexts direkt beim Rendern. Ist das Promise noch nicht erfüllt, unterbricht React die Komponente und zeigt die nächste Suspense-Grenze an, also einen Platzhalter wie einen Ladeindikator. Anders als Hooks darf use auch in Bedingungen oder Schleifen stehen.

Wichtig ist, woher das Promise kommt. Erzeugt eine Komponente es bei jedem Rendern neu, etwa mit use(fetchData()) direkt im Komponentenkörper, beginnt das Laden jedes Mal von vorn. React warnt in diesem Fall. Das Promise sollte deshalb außerhalb entstehen, zum Beispiel in einer Server Component, in einem Router-Loader oder in einer Datenbibliothek mit Cache, und als Prop hereinkommen:

import { Suspense, use } from 'react';

type User = { name: string };

function Profile({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise);
  return <h2>{user.name}</h2>;
}

export function ProfilePage({ userPromise }: { userPromise: Promise<User> }) {
  return (
    <Suspense fallback={<p>Profil wird geladen …</p>}>
      <Profile userPromise={userPromise} />
    </Suspense>
  );
}

Für die meisten Anwendungen bedeutet das: use ist ein Baustein für Frameworks und Datenbibliotheken. Bibliotheken wie TanStack Query oder die Datenfunktionen von Next.js bleiben für das Laden selbst sinnvoll.

Server Components und Server Functions

Server Components sind Komponenten, die nur auf dem Server laufen, etwa beim Build oder bei jeder Anfrage. Sie können direkt auf Datenbanken oder Dateien zugreifen, und ihr Code gelangt nicht in das JavaScript, das der Browser lädt. Mit React 19 sind sie Teil der stabilen Version. Ergänzend gibt es Server Functions, früher Server Actions genannt: Funktionen mit der Direktive 'use server', die auf dem Server laufen, sich aber aus Client-Komponenten aufrufen lassen, etwa als action eines Formulars.

// Server Component: läuft nur auf dem Server
import { db } from '@/lib/db';

export default async function ProductCatalog() {
  const products = await db.product.findMany();
  return (
    <ul>
      {products.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

Eine Einschränkung bleibt: React liefert die Grundlagen, nutzbar werden Server Components erst durch ein Framework oder einen Bundler, der sie unterstützt. Am weitesten verbreitet ist der App Router von Next.js. Wie Next.js 15 im Herbst 2024 React 19 eingebunden hat, beschreibt der Beitrag Next.js 15 und React 19: Was das Update brachte. Daneben arbeiten weitere Frameworks und Bundler an eigener Unterstützung.

Server Functions sind öffentlich erreichbare Endpunkte, auch wenn sie im Code wie normale Funktionen aussehen. Sie brauchen dieselbe Prüfung von Berechtigungen und Eingaben wie jede andere Schnittstelle. Wie ernst das ist, zeigte sich im Dezember 2025: Das React-Team veröffentlichte Sicherheitsupdates für eine kritische Lücke in den Server-Components-Paketen, über die Angreifer Code auf dem Server ausführen konnten. Wer Server Components einsetzt, sollte React und das Framework deshalb zügig aktualisieren.

Kleinere Änderungen mit großer Wirkung im Alltag

ref als normale Prop

Bisher brauchte eine Komponente forwardRef, um eine Ref an ein inneres Element weiterzugeben, etwa an ein Eingabefeld, das den Fokus erhalten soll. In React 19 ist ref für Funktionskomponenten eine gewöhnliche Prop. forwardRef funktioniert weiterhin, soll aber in einer späteren Version abgekündigt werden. Neu ist außerdem, dass Ref-Callbacks eine Aufräumfunktion zurückgeben dürfen, ähnlich wie Effekte.

Context direkt als Provider

Statt <ThemeContext.Provider value={theme}> genügt nun <ThemeContext value={theme}>. Das ist kein großer Schritt, macht Komponentenbäume aber lesbarer.

Metadaten und Ressourcen

Komponenten dürfen title, meta und link direkt rendern; React verschiebt diese Elemente automatisch in den Kopf des Dokuments. Für eine kleine Single-Page-Anwendung erspart das eine zusätzliche Bibliothek. Frameworks wie Next.js bieten mit ihren Metadaten-APIs aber meist mehr Komfort. Dazu kommen Funktionen wie preload und preconnect, mit denen eine Anwendung dem Browser früh mitteilt, welche Schriften, Skripte oder Server er bald braucht.

Bessere Fehlermeldungen

Hydrierungsfehler, also Abweichungen zwischen Server-HTML und dem, was der Browser rendert, meldet React 19 als einen zusammengefassten Unterschied statt als Kette verwirrender Warnungen. Außerdem lassen sich Fehler zentral über neue Optionen von createRoot abfangen und etwa an ein Monitoring weiterreichen.

Der React Compiler: eigenständig und unabhängig von React 19

Rund um die Veröffentlichung von React 19 bekam der React Compiler viel Aufmerksamkeit, und zunächst wurde er oft als Teil der neuen Version beschrieben. Tatsächlich ist er ein eigenständiges Werkzeug, das als Babel-Plugin in den Build-Prozess eingebunden wird. Er analysiert Komponenten und fügt die Memoisierung automatisch ein, die Entwickler:innen bisher von Hand mit useMemo, useCallback oder React.memo schrieben. Memoisierung heißt: Ein Ergebnis wird zwischengespeichert und nur neu berechnet, wenn sich die Eingaben ändern.

Im Dezember 2024 war der Compiler noch in der Erprobung. Seit Oktober 2025 liegt er in stabiler Version 1.0 vor. Er setzt React 19 nicht zwingend voraus, ältere Versionen ab React 17 lassen sich mit einem Zusatzpaket einbinden. Wie viel er bringt, hängt von der Anwendung ab; pauschale Prozentangaben sind wenig aussagekräftig. Am meisten profitieren Oberflächen mit vielen Komponenten, die unnötig neu rendern. Voraussetzung ist Code, der die Regeln von React einhält, etwa keine Änderung von Props während des Renderns. Die zugehörigen Lint-Regeln zeigen solche Stellen schon vorher an.

Migration von React 18 auf React 19

Der Umstieg ist für die meisten Anwendungen überschaubar, aber kein reines Versions-Update. React 19 entfernt APIs, die schon länger als veraltet galten:

• ReactDOM.render und ReactDOM.hydrate, ersetzt durch createRoot und hydrateRoot
• propTypes und defaultProps bei Funktionskomponenten, stattdessen TypeScript und Standardwerte in der Parameterliste
• String-Refs und der alte Context-Mechanismus von Klassenkomponenten
• findDOMNode und die UMD-Builds für das Einbinden per Script-Tag

Das React-Team hat dafür einen sinnvollen Weg vorgegeben. Zuerst auf React 18.3 aktualisieren, das Warnungen für alle betroffenen Stellen ausgibt. Diese beheben, dann auf 19 wechseln. Für viele Änderungen gibt es Codemods, also Skripte, die Quelltext automatisch umschreiben. In TypeScript-Projekten kommen geänderte Typen hinzu, etwa verlangt useRef nun immer einen Startwert.

Der häufigste Stolperstein liegt außerhalb des eigenen Codes: Bibliotheken für Komponenten, Formulare oder Tests müssen React 19 unterstützen. Ein Blick in deren Versionshinweise gehört vor jedes Update. Ältere Testwerkzeuge auf Basis von react-test-renderer sind abgekündigt; die React Testing Library ist der gängige Ersatz.

Was React 19 für Ihr Team bedeutet

React 19 ist ein solides, eher unspektakuläres Update im besten Sinn. Es nimmt Teams Arbeit ab, die bisher jede Anwendung neu erfand, vor allem bei Formularen und Ladezuständen. Die meisten Neuerungen lassen sich schrittweise einführen, alter Code läuft weitgehend weiter.

Unsere Einschätzung: Für Anwendungen auf React 18 lohnt sich der Umstieg auf die aktuelle 19er-Version, schon wegen der Sicherheitsupdates und der Unterstützung durch Bibliotheken. Actions und useOptimistic sind sofort nützlich, ganz ohne Framework. Server Components dagegen sind eine Architekturentscheidung, kein Feature zum Nachrüsten. Sie lohnen sich vor allem, wenn ohnehin ein Framework wie Next.js im Einsatz ist oder geplant wird. Überschätzt wird oft der React Compiler als Allheilmittel für Performance: Er ersetzt manuelle Memoisierung, nicht aber eine durchdachte Datenhaltung oder zu große Komponenten.

Wer ein Projekt auf React 19 heben, den Compiler einführen oder ein Team in Actions und Server Components einarbeiten möchte, findet auf der Seite zu React: Beratung, Coaching und Seminare unsere Angebote dazu.

Häufige Fragen zu React 19

Muss für React 19 die gesamte Codebasis überarbeitet werden?

Nein. Die meisten Komponenten laufen unverändert. Anpassungen sind dort nötig, wo entfernte APIs wie ReactDOM.render, String-Refs oder defaultProps bei Funktionskomponenten genutzt werden. Der Zwischenschritt über React 18.3 zeigt diese Stellen als Warnungen an, Codemods übernehmen einen Teil der Umstellung.

Ist der React Compiler Teil von React 19?

Nein, er ist ein eigenständiges Werkzeug, das in den Build eingebunden wird. Er passt gut zu React 19, funktioniert aber auch mit älteren Versionen ab React 17. Seit Oktober 2025 ist er als Version 1.0 stabil.

Lassen sich Server Components ohne Next.js nutzen?

Grundsätzlich ja, denn sie sind Teil von React und nicht von Next.js. Nötig ist aber ein Framework oder Bundler, der sie unterstützt. Next.js ist dabei am weitesten verbreitet und am längsten erprobt; andere Frameworks bieten eigene, teils noch junge Umsetzungen.

Brauchen Formulare in React 19 keine Formular-Bibliothek mehr?

Für einfache Formulare oft nicht. Actions, useActionState und useFormStatus decken Absenden, Ladezustand und Fehlermeldungen ab. Bei umfangreicher Validierung, vielen abhängigen Feldern oder mehrstufigen Formularen bleiben spezialisierte Bibliotheken eine sinnvolle Ergänzung.