So haben wir SWR in einem Projekt eingesetzt – und warum wir es lieben

Warum SWR?

Kürzlich hatten wir bei SDH die Gelegenheit, ein Projekt mit React und Unterstützung durch Redux Toolkit zu entwickeln. Das Problem: Zwar wurden die Daten im Store gehalten und von dort geholt, aber es gab keinen Caching‑Mechanismus in der App.  Und Dutzende von Responses im State zu horten, ist nicht gerade meine Vorstellung von cool. Wie auch immer – man verlor sich schnell in all den State Slices, trotz Toolkit.  

Mehr noch: Das Ganze hatte zu diesem Zeitpunkt null Einfluss auf das Backend. Mit diesen eisberggroßen Datenbrocken brauchten manche Requests eine Ewigkeit.  Und da die UI hauptsächlich aus langen Listen mit wenigen CRUD‑Operationen bestand,  wurde schnell klar, dass ein Cache hier äußerst praktisch wäre. Also fiel die Wahl auf SWR – eine Library der Entwickler von Vercel (auch bekannt für Next.js).

Was ist SWR?

Magst du Definitionen lesen? Hoffentlich nicht, denn das hier wird eine der kürzesten überhaupt. „SWR ist eine React Hooks‑Library für Remote Data Fetching“. Das war’s. Einfach? Ja – aber ich zeige dir jetzt, dass SWR auch sehr leistungsfähig ist. Falls du dich fragst: SWR steht für stale‑while‑revalidate. Das erklärt schon die Funktionsweise. SWR liefert Daten aus dem Cache (stale), schickt einen Fetch‑Request, um aktualisierte Daten zu holen (revalidate), und liefert dann die neuen Daten.  Wie gesagt: simpel. 

Warum wir SWR lieben

Man erkennt schnell, wie SWR die eingangs beschriebenen Probleme eliminiert. Dank SWR haben wir:

• die UI (nach den ersten Requests) dank Caching reibungslos zum Laufen gebracht 
• nahezu alle Slices mit API‑Daten samt zugehöriger Logik entfernt
• den Ablauf der Revalidierung nach CRUD‑Operationen auf Collections vereinfacht
• die Entwicklung neuer, API‑abhängiger Features beschleunigt

Wie haben wir die Library nun eingesetzt, um diese magischen Ergebnisse zu erzielen? 

Wie SWR funktioniert

Schon nach kurzer Zeit zeigte sich: SWR ist schlicht und sehr anwenderfreundlich. Lust auf einen API‑Request mit SWR? Bitte sehr:

Der einzige Haken ist der Fetcher. Das ist einfach deine eigene Funktion zum Laden der Daten. In der Anwendung, an der wir gearbeitet haben, war axios bereits mit kompletter Config (Interceptors, Headers, Base URL etc.) eingerichtet, also haben wir unsere axios‑Instanz so gewrappt und unseren eigenen Fetcher gebaut:

Der gesamte Hook kann dann so schlicht aussehen (Error Handling lassen wir hier der Einfachheit halber weg):

Und ... das war’s! Wir haben einen Hook für das Fetching von API‑Daten gebaut – mit all den SWR‑Goodies. Immer wenn dieser Hook aufgerufen wird, liefert er zuerst bereits geladene Daten (falls vorhanden) und revalidiert dann, um anschließend die neue Collection zurückzugeben.

SWR bringt out of the box eine Reihe vorkonfigurierter Parameter mit (alle sind hier gelistet), die die Arbeit damit zum Kinderspiel machen. Eine Lieblingsoption ist dedupingInterval.

Typischer Use Case: Daten in einer Komponente holen, die Komponente weiterentwickeln, die Children wachsen dir über den Kopf – und plötzlich braucht ein Child in der vierten Ebene die Daten. Diese Daten ohne großen Aufwand dorthin zu bekommen und doppelte Requests zu vermeiden, ist immer eine Herausforderung. Mit SWR geht’s einfach: Verwende den Hook erneut ... Das deduping‑Intervall lässt innerhalb eines festgelegten Zeitraums (standardmäßig 2 Sekunden) keinen weiteren Request zu. Klingt fair.

„Aber wenn ich den Endpoint aufrufe und er dieselben Daten wie zuvor zurückgibt, rendert meine Komponente doch trotzdem neu.“ Tut sie nicht: SWR setzt auf Deep Comparison, ein Re‑Render wird nur ausgelöst, wenn sich die Daten wirklich geändert haben. Und die Vergleichsfunktion lässt sich natürlich anpassen. 

Datenmutation

Du wirst einwenden: Daten per GET zu holen ist immer leicht – aber was ist mit dem Mutieren? Das ist doch sicher komplizierter. Nicht wirklich, Mutationen müssen kein Albtraum sein, und ich war überrascht, wie einfach sich Daten mit SWR mutieren lassen (nachdem ich zuvor schon meinen Spaß mit Apollo hatte). Hier ein Praxisbeispiel:

In diesem Beispiel ist mutate eine aus SWR importierte Funktion, und /users ist der Key, den wir im useUsers‑Hook vergeben haben (muss nicht die Endpoint‑URL sein – Key und URL lassen sich getrennt angeben).

Wenn du ein einzelnes Entity (Objekt) aus einer größeren Collection separat cachen und aktualisieren möchtest, mutierst du es einfach über seinen Key so:

Klingt zu einfach? Es ist einfach. Probier’s aus – du sparst dir damit vermutlich eine Menge umfangreicher Redux‑Logik und Debugging deiner API‑Calls.

SWR‑Integrationen

Wie du siehst, ist die Implementierung von SWR simpel; mit ein paar netten Kniffen  lassen sich die obigen Beispiele schnell auf ein höheres, abstrakteres Niveau heben. Natürlich ist SWR nicht darauf beschränkt – es gibt zahlreiche Optionen und Integrationen:

GraphQL‑Integration

Error Handling mit Retry‑Optionen

Auto‑Revalidation

Pagination‑Support (auch für Infinite Loading)

Data Prefetching

und vieles mehr (Dokumentation)

Wir fanden die Arbeit mit SWR super und werden es für künftige Projekte definitiv in Betracht ziehen. Wenn du mehr über diese großartige Library erfahren möchtest, findest du Dokumentation, Configs und Beispiele auf der offiziellen Website hier.

Viel Spaß beim Coden!