SWR-Grundlagen: Stale-While-Revalidate

SWR steht für Stale-While-Revalidate, eine in RFC 5861 definierte HTTP-Cache-Strategie. Dabei werden dem Benutzer zunächst veraltete (zwischengespeicherte) Daten angezeigt. Anschließend werden sie im Hintergrund erneut validiert und die UI wird aktualisiert, sobald aktuelle Daten eintreffen.

Dieser Ansatz stellt die wahrgenommene Performance in den Vordergrund: Benutzer sehen Daten sofort, statt auf eine Netzwerk-Rundreise zu warten.

Bei herkömmlichen Lademustern sehen Benutzer bei jeder Navigation einen Spinner. Mit SWR sehen sie sofort die zuletzt bekannten Daten, und die UI wird im Hintergrund unauffällig aktualisiert, wenn sich die Daten geändert haben.

Dadurch fühlen sich Anwendungen deutlich schneller an, und die kognitive Unterbrechung durch Ladezustände wird reduziert.

SWR validiert Daten automatisch neu, wenn das Browserfenster wieder den Fokus erhält (der Benutzer wechselt den Tab und kehrt zurück), die Netzwerkverbindung nach einer Offline-Phase wiederhergestellt wird, explizit mutate() aufgerufen wird oder ein konfigurierbarer refreshInterval-Timer auslöst.

Diese automatischen Auslöser halten die Daten aktuell, ohne dass Sie die Logik zum erneuten Abrufen manuell verwalten müssen.

Ein SWR-Key kann sich in einem von mehreren Zuständen befinden: loading (keine zwischengespeicherten Daten, erster Abruf läuft), revalidating (zwischengespeicherte Daten vorhanden, Aktualisierung im Hintergrund läuft), error (Anfrage fehlgeschlagen) oder success (aktuelle Daten verfügbar).

Wenn Sie diese Zustände verstehen, können Sie korrekte Lade-Skeletons und Fehler-UIs erstellen.

SWR verwaltet einen globalen In-Memory-Cache, dessen Schlüssel der Anfrage-Key ist (typischerweise eine URL-Zeichenfolge). Jede Komponente, die denselben Key anfordert, erhält denselben zwischengespeicherten Wert und nimmt am selben Revalidierungszyklus teil.

Dank dieser automatischen Deduplizierung können 10 Komponenten jeweils useSWR mit demselben Key aufrufen, wobei nur eine Netzwerkanfrage gesendet wird.

SWR trennt die Cache-Verwaltung vom eigentlichen Abrufen der Daten. Sie stellen eine Fetcher-Funktion bereit: eine async-Funktion, die den Key entgegennimmt und die Daten zurückgibt.

Der Fetcher ist austauschbar: Verwenden Sie fetch, axios, graphql-request oder eine beliebige asynchrone Datenquelle. SWR übernimmt das Caching und die Revalidierung unabhängig davon, wie der Fetcher funktioniert.

Umschließen Sie Ihre App mit SWRConfig und übergeben Sie ein value-Prop, das eine Fetcher-Funktion enthält: value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}. Jeder useSWR-Aufruf, bei dem das Fetcher-Argument fehlt, verwendet diesen globalen Standardwert.

Dadurch zentralisieren Sie die API-Konfiguration (Basis-URL, Authentifizierungs-Header) an einer Stelle, ohne sie in jedem Hook-Aufruf zu wiederholen.

Das klassische Muster verwendet useEffect + useState, um Lade-, Daten- und Fehlerzustände manuell zu verwalten. SWR ersetzt all das durch einen einzigen Hook-Aufruf, der Caching, Deduplizierung, Aktualisierungen im Hintergrund und automatische Wiederholungen bei Fehlern übernimmt.

Die Codeeinsparung ist beträchtlich: Eine typische Komponente zum Abrufen von Daten schrumpft von mehr als 20 Zeilen auf 3 Zeilen.

Der Key identifiziert eine Anfrage eindeutig. Verwenden Sie in einfachen Fällen die URL-Zeichenfolge. Für Anfragen mit Parametern verwenden Sie einen Array-Key: [url, params], wobei params ein stabiles Objekt oder eine Zeichenfolge ist. Null deaktiviert die Anfrage.

Ein gut entworfener Key sorgt dafür, dass zusammengehörige Anfragen Cache-Einträge gemeinsam nutzen und nicht zusammengehörige Anfragen nicht miteinander kollidieren.

SWR geht intelligent mit der Revalidierung um: Das dedupingInterval (Standardwert: 2 Sekunden) verhindert, dass mehrere Revalidierungen gleichzeitig ausgelöst werden, wenn viele Komponenten gleichzeitig eingebunden werden. Innerhalb des Deduplizierungsfensters wird pro Key nur eine Anfrage gesendet.

Dadurch werden Thundering-Herd-Probleme vermieden, die in großen Komponentenbäumen häufig auftreten, wenn viele Komponenten dieselben Daten abrufen.

SWR wird von Vercel entwickelt, dem Unternehmen hinter Next.js, und die Integration ist nahtlos. Mit getServerSideProps oder getStaticProps können Sie Daten vorab abrufen, und SWR übernimmt diesen vorab abgerufenen Wert auf dem Client.

So erhalten Sie serverseitig gerendertes initiales HTML mit automatischer clientseitiger Revalidierung beim Mounten und kombinieren die Vorteile von SSR und SWR.

Welche der folgenden Aktionen löst die SWR-Revalidierung standardmäßig NICHT aus?

SWR implementiert die Strategie Stale-While-Revalidate: zwischengespeicherte Daten sofort ausliefern, im Hintergrund erneut validieren und die UI aktualisieren, sobald aktuelle Daten verfügbar sind. Eine Revalidierung wird bei Fokus, erneuter Verbindung, mutate und beim Polling ausgelöst. Der globale Cache dedupliziert Anfragen über mehrere Komponenten hinweg, und die Fetcher-Funktion kann vollständig ausgetauscht werden.

Dieses Modell vereinfacht den Code zum Abrufen von Daten erheblich und sorgt zugleich für eine schnellere wahrgenommene Performance.