Wichtige Standardeinstellungen

TanStack Query ist standardmäßig mit aggressiven, aber sinnvollen Voreinstellungen konfiguriert. Manchmal können diese Standardeinstellungen neue Benutzer überraschen oder das Lernen/Debuggen erschweren, wenn sie dem Benutzer unbekannt sind. Behalten Sie sie im Hinterkopf, während Sie TanStack Query weiter lernen und verwenden.

• Query-Instanzen über useQuery oder useInfiniteQuery betrachten standardmäßig zwischengespeicherte Daten als veraltet.

Um dieses Verhalten zu ändern, können Sie Ihre Abfragen sowohl global als auch pro Abfrage mit der Option staleTime konfigurieren. Die Angabe einer längeren staleTime bedeutet, dass Abfragen ihre Daten nicht so oft neu abrufen.

• Eine Abfrage mit einer gesetzten staleTime gilt als aktuell, bis diese staleTime abgelaufen ist.

  • Setze staleTime auf z.B. 2 * 60 * 1000, um sicherzustellen, dass Daten aus dem Cache gelesen werden, ohne jegliche Refetches auszulösen, für 2 Minuten oder bis die Abfrage manuell invalidiert wird.
  • Setze staleTime auf Infinity, um niemals einen Refetch auszulösen, bis die Abfrage manuell invalidiert wird.
  • Setze staleTime auf 'static', um niemals einen Refetch auszulösen, selbst wenn die Abfrage manuell invalidiert wird.

• Veraltete Abfragen werden automatisch im Hintergrund neu abgerufen, wenn

  • Neue Instanzen der Abfrage gemountet werden
  • Das Fenster den Fokus erhält
  • Das Netzwerk wieder verbunden wird

Das Setzen von staleTime ist der empfohlene Weg, übermäßige Neuabrufe zu vermeiden. Sie können aber auch die Zeitpunkte für Neuabrufe anpassen, indem Sie Optionen wie refetchOnMount, refetchOnWindowFocus und refetchOnReconnect setzen.

• Abfragen können optional mit einem refetchInterval konfiguriert werden, um Abfragen periodisch auszulösen. Dies ist unabhängig von der Einstellung staleTime.

• Abfrageergebnisse, für die keine aktiven Instanzen von useQuery, useInfiniteQuery oder Query-Observer vorhanden sind, werden als "inaktiv" gekennzeichnet und bleiben im Cache, falls sie später erneut verwendet werden.

• Standardmäßig werden "inaktive" Abfragen nach 5 Minuten aus dem Garbage Collector entfernt.

  Um dies zu ändern, können Sie die Standard- gcTime für Abfragen auf etwas anderes als 1000 * 60 * 5 Millisekunden ändern.

• Fehlgeschlagene Abfragen werden still 3 Mal mit exponentieller Rückschrittverzögerung erneut versucht, bevor ein Fehler erfasst und in der Benutzeroberfläche angezeigt wird.

  Um dies zu ändern, können Sie die Standardoptionen retry und retryDelay für Abfragen auf etwas anderes als 3 und die standardmäßige exponentielle Rückschrittfunktion ändern.

• Abfrageergebnisse werden standardmäßig strukturell geteilt, um zu erkennen, ob sich Daten tatsächlich geändert haben. Wenn nicht, bleibt die Datenreferenz unverändert, um die Wertstabilisierung im Hinblick auf useMemo und useCallback zu verbessern. Wenn Ihnen dieses Konzept fremd ist, machen Sie sich keine Sorgen! In 99,9 % der Fälle müssen Sie dies nicht deaktivieren und es macht Ihre App performanter, ohne zusätzliche Kosten für Sie.

  Strukturelles Teilen funktioniert nur mit JSON-kompatiblen Werten. Alle anderen Werttypen werden immer als geändert betrachtet. Wenn Sie beispielsweise aufgrund großer Antworten Leistungsprobleme haben, können Sie diese Funktion mit dem Flag config.structuralSharing deaktivieren. Wenn Sie mit nicht-JSON-kompatiblen Werten in Ihren Abfrageantworten arbeiten und trotzdem erkennen möchten, ob sich Daten geändert haben oder nicht, können Sie eine eigene benutzerdefinierte Funktion als config.structuralSharing bereitstellen, um einen Wert aus den alten und neuen Antworten zu berechnen und Referenzen nach Bedarf beizubehalten.