Rohe fetch()-Aufrufe in useEffect (GENAU wie in Kapitel 8) skalieren SCHLECHT – TanStack Query übernimmt Caching, Neuladen bei Fenster-Fokus und Ladezustände, OHNE dass wir das SELBST verwalten müssen.

Den QueryClient einrichten

import { StrictMode } from 'react';
import { createRoot } from 'react-dom/client';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import App from './App';
import './index.css';

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 30_000,
      retry: 1,
    },
  },
});

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <QueryClientProvider client={queryClient}>
      <App />
    </QueryClientProvider>
  </StrictMode>,
);

staleTime: 30_000 bedeutet: Daten gelten 30 Sekunden lang als "frisch genug", INNERHALB dieser Zeit liefert TanStack Query den GECACHTEN Wert SOFORT, OHNE einen neuen Request zu senden.

Der DevTools-Schnellstart

npm install @tanstack/react-query-devtools

import { ReactQueryDevtools } from '@tanstack/react-query-devtools';

// innerhalb von QueryClientProvider, NEBEN <App />:
<ReactQueryDevtools initialIsOpen={false} />

Ein SICHTBARES Panel (NUR im Entwicklungsmodus, wird für Produktions-Builds AUTOMATISCH entfernt), das JEDEN Query-Status, Cache-Eintrag und Hintergrund-Refetch LIVE anzeigt – UNVERZICHTBAR beim Debuggen der kommenden Kapitel.

Warum nicht Redux oder Context für Server-Daten

TanStack Query löst ein ANDERES Problem als klassisches State-Management (Redux, useState+Context): SERVER-Daten sind NIEMALS wirklich "im Besitz" des Clients, sie können sich JEDERZEIT ändern (auch durch ANDERE Nutzer, GENAU wie in Block 8 gezeigt) – TanStack Query behandelt sie KONSEQUENT als "zwischengespeicherte Kopie eines entfernten Zustands", nicht als lokalen Anwendungszustand.