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 injectQuery oder injectInfiniteQuery 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.

  • Setzen Sie staleTime z. B. auf 2 * 60 * 1000, um sicherzustellen, dass Daten aus dem Cache gelesen werden, ohne jegliche erneuten Abrufe auszulösen, für 2 Minuten oder bis die Query manuell invalidiert wird.
  • Setzen Sie staleTime auf Infinity, um niemals einen erneuten Abruf auszulösen, bis die Query manuell invalidiert wird.
  • Setzen Sie staleTime auf 'static', um niemals einen erneuten Abruf auszulösen, selbst wenn die Query 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.

• Query-Ergebnisse, für die es keine aktiven Instanzen von injectQuery, injectInfiniteQuery oder Query-Observern mehr gibt, werden als "inaktiv" bezeichnet und verbleiben im Cache, falls sie zu einem späteren Zeitpunkt 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.

• Query-Ergebnisse werden standardmäßig strukturell geteilt, um zu erkennen, ob sich Daten tatsächlich geändert haben. Wenn dies nicht der Fall ist, bleibt die Datenreferenz unverändert, um die Wertstabilisierung im Hinblick auf die Festlegung von Signalwerten 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.