Ein Schalter, den jemand in deiner Oberfläche umlegt, gehört dir. Du weißt jederzeit, wie er steht, und er ändert sich nur, wenn jemand ihn anfasst. Eine Liste von Bestellungen gehört dir nicht. Sie liegt auf einem Server, jemand anderes ändert sie dort, und deine Kopie wird schlecht, während sie auf dem Bildschirm steht.
Deine Daten gehören dir nicht
Genau diese Unterscheidung meint der Begriff Server-State: asynchron
geladene, geteilte, veraltende Daten. Behandelt man sie wie lokalen Zustand,
baut man in jeder Komponente dieselben drei Fälle nach — lädt, fehlgeschlagen,
hat Daten — und dazu die Frage, wann neu geladen wird. Das ist der
Boilerplate, den useEffect plus useState zuverlässig erzeugt.
Der Query Key ist ein Abhängigkeits-Array
Der unscheinbarste Teil hat die größte Wirkung. Ein Query Key verhält sich wie das Abhängigkeits-Array eines Effekts: Alles, was das Ergebnis beeinflusst, gehört hinein — Filter, Seitenzahl, Sortierung. Fehlt der Filter im Key, wechselt jemand die Auswahl und sieht die Daten der vorherigen. Aus Sicht des Caches ist ja nichts passiert, der Key war derselbe.
Kein Ersatz für Zustand oder Redux
Ein verbreitetes Missverständnis: Das ersetzt keine Zustandsverwaltung für die Oberfläche. Ob eine Seitenleiste offen ist, bleibt Sache deines bisherigen Ansatzes. Ersetzt wird der Teil, der sich mit Serverdaten beschäftigt — und der ist in vielen Projekten der größere.
Mehr dazu im Seminar
Wie Caching, Invalidierung nach Mutationen und optimistische Updates zusammenspielen, zeigt das Modul React v19 - TanStack Query v5 — mit Video und Kapitelübersicht.