React Query (TanStack) vs SWR vs useEffect — kompletny przewodnik po fetchingu w 2026

Data fetchingData fetching to pobieranie danych z serwera lub API oraz obsługa cache, błędów, retry i stanu ładowania., czyli sztuka sensownego pobierania danych, to bodajże najstarszy problem w świecie Reacta i jednocześnie decyzja, którą architekci systemów potrafią najmocniej zaniedbać. Napisanie podstawowego useEffect wraz z fetch jest dziecinnie proste. Jednak dopisanie do niego logiki, która poprawnie obsłuży cache, usunie zdublowane zapytania, bezbłędnie zadba o powtórzenia w razie błędów (retry) i elegancko wybroni się przed nadpisywaniem starych wyników (race conditions)... to już temat na kilka dobrych miesięcy ciężkiej pracy całego zespołu.

Mamy 2026 rok i na stole wylądowały w zasadzie trzy dominujące rozwiązania: potężny kombajn TanStack Query, zwinny i lekki pakiet SWR od Vercela oraz uparty klasyk useEffect (stosowany głównie przez zespoły cierpiące na alergię na dodawanie nowych bibliotek do pliku package.json). W tym artykule zderzymy ze sobą całą trójkę i sprawdzimy, jak w to wszystko wpisują się rewelacyjne Server Components.

Hierarchia środowiska – ścieżka podejmowania decyzji na skróty

Nie masz czasu na długie lektury? Oto ściągawka w 30 sekund:

1. Server Components (w Next.js lub Remix) — Twoja pierwsza linia frontu. Jeśli coś da się zaciągnąć i wrzucić do HTML-a bezpośrednio z poziomu serwera, zrób to tam. Nie martwisz się o logikę cache'owania, unikasz wpychania JavaScriptu do przeglądarki.
2. TanStack Query — Podstawowe działo, jeśli jednak potrzebujesz uderzyć po dane z poziomu frontendu (klienta). Potężne, stabilne i przeładowane niezbędnymi funkcjami.
3. SWR — Gdy budujesz coś bardzo minimalistycznego i potrzebujesz jedynie leciutkiej odskoczni pod podstawowe odpytywania.
4. Opcja z useEffect + fetch — Zakazane słowo przy twardej architekturze korporacyjnej. Trzymaj to z dala od środowisk produkcyjnych.

Dlaczego useEffect potrafi mocno podciąć skrzydła?

Zacznijmy w ogóle od tego, na jakich minach kładzie nas klasyczne, podręcznikowe podejście:

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState(null)
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState(null)
 
  useEffect(() => {
    let cancelled = false
    setLoading(true)
 
    fetch(`/api/users/${userId}`)
      .then((r) => r.json())
      .then((data) => {
        if (!cancelled) {
          setUser(data)
          setLoading(false)
        }
      })
      .catch((err) => {
        if (!cancelled) {
          setError(err)
          setLoading(false)
        }
      })
 
    return () => {
      cancelled = true
    }
  }, [userId])
 
  if (loading) return <Spinner />
  if (error) return <Error error={error} />
  return <Profile user={user} />
}

Powyższy blok kodu technicznie... działa. Problem polega na tym, że skrywa mnóstwo architektonicznych potknięć:

1. Wycieki na zasobach bazy (Brak cache'owania). Wyobraź sobie, że wchodzisz w zakładkę /users/123, potem skaczesz pod /users/456 by za moment znów wrócić na stare /users/123. Przeglądarka zaciągnie kod od zera za każdym jednym razem. Choć rekordy w bazie się nie zmieniły – Ty niepotrzebnie płacisz za to w rachunkach do serwera.

2. Marnowanie łącza (Brak deduplikacji). Jeżeli na jednej stronie pięć różnych małych komponentów zechce odczytać dane z /api/users/123, "goły" fetch potulnie wyśle w świat pięć osobnych requestów. Kompletny absurd i to bardzo powszechny.

3. "Kto pierwszy ten lepszy" (Race conditions). Nawet z opcją zmyślnej blokady (flaga cancelled), jeśli szybko przebierasz między podstronami, asynchroniczne odpowiedzi mogą spłynąć do komponentu w całkowicie złej kolejności. Twój kod wysypie starą odpowiedź, chociaż przed momentem pytałeś już o nową.

4. Panika przy błędach (Brak retry). Padło Ci lokalne połączenie na ułamek sekundy w pociągu? Koniec. Użytkownik dostaje brzydki Error i jeśli sam nie wciśnie klawisza f5 (odśwież), utknie tam na amen.

5. Złe doświadczenia w interfejsie (Brak odświeżeń w tle). Odchodzisz od biurka, w międzyczasie Twoi znajomi dopisali wpisy w grupie. Wracasz za kwadrans, ale strona twardo wisi na tym co widziała przed wyjściem. Bez odświeżania na tło nie wiesz nawet, że informacje są przestarzałe.

6. Frustrujący wskaźnik ładowania (Brak Optymistycznych Aktualizacji). Zostawiasz komentarz, po czym wlepiasz wzrok w kręcące się kółko, modląc się, by proces przebiegł pomyślnie. Nowoczesne systemy pokazują Twój komentarz od razu, nie każąc Ci czekać na zielone światło od API.

Widzisz problem? Oczywiście, jako dzielny rzemieślnik mógłbyś to obudować samemu w kodzie, ale z ręką na sercu — napisanie tych warstw od nowa to tysiące linii kodu i setki potknięć (bugów). Po co wyważać otwarte drzwi, skoro inni mądrzy specjaliści od bibliotek zrobili to świetnie przed nami?

TanStack Query — Prawdziwy hegemon roku 2026

TanStack Query (w starych dziejach używany pod szyldem React Query) to paczka, która powyższe problemy kompresuje do śmiesznie prostych dziesięciu linijek kodu.

import { useQuery } from '@tanstack/react-query'
 
function UserProfile({ userId }: { userId: string }) {
  const {
    data: user,
    isLoading,
    error,
  } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetch(`/api/users/${userId}`).then((r) => r.json()),
  })
 
  if (isLoading) return <Spinner />
  if (error) return <Error error={error} />
  return <Profile user={user} />
}

Tylko tyle. Co w pakiecie dostarcza Ci ten kod?

• Genialnie prosty bufor - rozbija cache na podstawie podanego klucza (czyli np. ['user', userId]). Każdy kolejny komponent podpięty pod ten klucz, bez pardonu doczepi się do wyniku i daruje sobie szukanie danych na świeżo w bazie.
• Magiczna Deduplikacja - jak już wcześniej wspomniałem, wszystkie prośby równoległe zostają zebrane i wysłane jednym zgrabnym "kurierem" (promisem).
• Walka do końca (Retry) - Domyślnie skrypt walczy jeszcze trzykrotnie, po równych odstępach odrzucenia (exponential backoff) zanim definitywnie "rzuci ręcznikiem".
• Natychmiastowe aktualizacje dla wracających - Zmienisz kartę by sprawdzić maila? TanStack na moment przed Twoim powrotem odpyta API, żeby zaserwować Ci na ekran najbardziej "świeżą" treść.
• Rewalidacja Stale-while - Pokaże to, co do tej pory uzbierał w buforze w błyskawicznym trybie, żeby tylko w tle móc doładować i uaktualnić wartości.

Przechodzimy do małego wdrożenia (Setup)

npm install @tanstack/react-query

Teraz mała owijka dla reszty aplikacji:

// src/providers.tsx
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'
 
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 60 * 1000, // Ile czasu dane są u nas uznawane za tzw. świeże (tu ucięte po 1 minucie)
      gcTime: 5 * 60 * 1000, // Jak długo aplikacja przetrzymuje klucze i historię w nieużywanej zakładce - śmieciarz odpala po 5 minutach!
    },
  },
})
 
export function Providers({ children }) {
  return (
    <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
  )
}

Mała podpowiedź jeśli pracujesz nad stosem od Next.js z App Routerem — tam upewnij się, żeby Twój wbudowany "klient do zapytań" stał się funkcją opartą per każde wejście a nie o jeden instancyjny, wspólny "singleton"! Dokumentacja na oficjalnych stronach przeprowadzi Cię przez to wzorowo.

Wbudowane, agresywne domyślne zasady od twórców (Które trzeba znać by nie płakać!)

TanStack nie "prosi". TanStack narzuca swoje żelazne i niezwykle czułe ramy na cały framework. Nieznajomość tych domyślnych funkcji bywa niezwykle myląca dla programistów:

Co ze zmianami pod dane? Wyprowadzamy Mutacje

import { useMutation, useQueryClient } from '@tanstack/react-query'
 
function AddComment({ postId }: { postId: string }) {
  const queryClient = useQueryClient()
 
  const mutation = useMutation({
    mutationFn: (text: string) =>
      fetch(`/api/posts/${postId}/comments`, {
        method: 'POST',
        body: JSON.stringify({ text }),
      }),
    onSuccess: () => {
      // Skasowaliśmy bufor dla tego posta by zmusić paczkę do uaktualnień!
      queryClient.invalidateQueries({ queryKey: ['comments', postId] })
    },
  })
 
  return (
    <form
      onSubmit={(e) => {
        e.preventDefault()
        const text = new FormData(e.currentTarget).get('text') as string
        mutation.mutate(text)
      }}
    >
      <input name="text" />
      <button disabled={mutation.isPending}>Wyślij</button>
    </form>
  )
}

Jeden mały wpis a magii znowu mamy pod dostatkiem. Kiedy zapytanie przejdzie test "Zrobiono Pomyślnie" (onSuccess), bufor dla wpisów o tagu komentarzy (dla danego identyfikatora wpisu postId) natychmiast ulega przedawnieniu. Rezultat? Skrypt "TanStacka" wykrzykuje o nowym powiewie informacji od bazy i ładuje na widok zaktualizowaną dyskusję dla każdego użytkownika operującego obecnie pod tym wpisem!

Oczaruj klienta optymistycznymi wczytywaniami (Optimistic updates)

Kto chce czekać po wysłaniu posta by powitać potwierdzenie bycia odebranym od opieszałego pociągu komunikacyjnego dla bazy po np dalekich serwerach Amerykańskich (z tzw strzałów post na logice asynchronicznej)? Zbuduj na ekranach opcję rzucenia powiadomienia a'la Messenger: "Widać że weszło bezbłędnie z mety, czekamy na puste weryfikacje za kulisami w kodzie".

const mutation = useMutation({
  mutationFn: (text: string) => addComment(postId, text),
  onMutate: async (text) => {
    // Wciskasz hamulec by w tym wariancie nic Ci się po bazie przez ułamki na ekranach przypadkiem nie ułożyło z opóźnień:
    await queryClient.cancelQueries({ queryKey: ['comments', postId] })
 
    // Zrób fotkę ze stanu do tej pory wypracowanych rozmów (na wypadek katastrofy sieci i potrzeby cofnięć awaryjnych)
    const previousComments = queryClient.getQueryData(['comments', postId])
 
    // Optymistycznie dodajemy komentarz do cache, zanim serwer potwierdzi zapis
    queryClient.setQueryData(['comments', postId], (old: Comment[]) => [
      ...old,
      { id: 'temp-' + Date.now(), text, createdAt: new Date() },
    ])
 
    return { previousComments }
  },
  onError: (err, text, context) => {
    // Jeżeli faktycznie jednak poszło coś do sieci źle, wgrywasz bezpiecznie zapasowy punkt dawnej dyskusji bez żadnego potu
    queryClient.setQueryData(['comments', postId], context.previousComments)
  },
  onSettled: () => {
    // Potem, by ukrócić wszystkie wariacje "szkieletu kodu u fałszywek bufora", żądasz rzutowania w stan "odśwież natychmiast całą logikę komentarza by odetchnąć i zamknąć puste identyfikatory logiki "temp-Date.now()""
    queryClient.invalidateQueries({ queryKey: ['comments', postId] })
  },
})

Cały kod zajmuje trochę więcej niż nowe bajery po paczce w postaci haków w najnowszych, bazowych systemach (np useOptimistic od React z lat 19) ale uwierz mi — otrzymujesz na nim wielokrotnie precyzyjniejsze kontrolki kierownicze.

Ciągnące się w nieskończoność skrypty od list (Infinite queries)

Paginacje na "Load More" dla systemów bazodanowych?

import { useInfiniteQuery } from '@tanstack/react-query'
 
function PostList() {
  const { data, fetchNextPage, hasNextPage, isFetchingNextPage } =
    useInfiniteQuery({
      queryKey: ['posts'],
      queryFn: ({ pageParam = 1 }) =>
        fetch(`/api/posts?page=${pageParam}`).then((r) => r.json()),
      getNextPageParam: (lastPage) => lastPage.nextPage ?? undefined,
      initialPageParam: 1,
    })
 
  return (
    <>
      {data?.pages.map((page, i) => (
        <Fragment key={i}>
          {page.posts.map((post) => (
            <PostCard key={post.id} post={post} />
          ))}
        </Fragment>
      ))}
 
      {hasNextPage && (
        <button onClick={() => fetchNextPage()} disabled={isFetchingNextPage}>
          {isFetchingNextPage ? 'Ładowanie w toku...' : 'Dawaj więcej wpisów!'}
        </button>
      )}
    </>
  )
}

Jeśli przy okazji renderujesz bardzo długie listy wyników, połącz to z wirtualizacją, by nie obciążać przeglądarki tysiącami elementów DOM — szczegóły w artykule Wirtualizacja list w React — kiedy TanStack Virtual ratuje FPS.

Co w trawie piszczy o SWR — odświeżenie bez nadwagi

SWR (od sformułowania "stale-while-revalidate") to mniejszy, zwinny kuzyn na rynkach od zaciągania danych, za którego odpowiada z reguły potężna załoga w Vercel. Myśl o nim jak o w pełni podobnej platformie co TanStack z tym by na paczkach ucinać masowe gigabajty (na suche wyniki rzędu ~4 KB na korzyść molocha rzutowanego w rzędzie ~13 KB u starszego z rodziny frameworka dla Query).

import useSWR from 'swr'
 
function UserProfile({ userId }: { userId: string }) {
  const {
    data: user,
    isLoading,
    error,
  } = useSWR(`/api/users/${userId}`, (url) => fetch(url).then((r) => r.json()))
 
  if (isLoading) return <Spinner />
  if (error) return <Error error={error} />
  return <Profile user={user} />
}

Przy bliższym spojrzeniu oba narzędzia mają dużo wspólnego, ale różnią się w kilku istotnych punktach:

Prostota – tu wygrywa SWR. Ma mniejsze API i niższy próg wejścia, więc do prostych projektów i mniejszych aplikacji jest wygodniejszym wyborem.

Bogactwo funkcji – tu wygrywa TanStack Query. Daje znacznie więcej narzędzi do złożonych aplikacji: dynamiczne klucze, rozbudowaną inwalidację cache po mutacjach, optymistyczne aktualizacje i mechanizm anulowania zapytań (query cancellation), który natychmiast przerywa fetch, gdy użytkownik np. cofnie się przed załadowaniem danych.

Typowanie TypeScript – TanStack Query ma dopracowaną integrację z TypeScriptem, z dobrą inferencją typów bez nadmiaru ręcznych adnotacji generycznych.

Reguła wyboru jest prosta: do rozbudowanych aplikacji z wieloma widokami, panelami i mutacjami (dashboardy, SaaS, e-commerce) bierz TanStack Query. Do prostszych projektów — małych paneli, stron marketingowych — wystarczy lżejszy SWR. Oba są solidne i sprawdzone w produkcji.

Jak to gra z Server Components

Złota reguła architektury w App Routerze brzmi: zanim pobierzesz dane na kliencie, zapytaj, czy w ogóle muszą tam trafić. W nowych aplikacjach Next.js większość początkowego pobierania danych powinna dziać się na serwerze, w Server Components:

// app/users/[id]/page.tsx — Server Component (Next.js 15+)
async function UserPage({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params
  const user = await fetchUser(id) // pobranie wykonuje się na serwerze
  return <Profile user={user} />
}

Do przeglądarki nie trafia wtedy żaden JavaScript fetchujący — serwer pobiera dane i wysyła gotowy HTML. Znikają wodospady zapytań po stronie klienta i koszt wykonania na słabszych urządzeniach. Ten sam model „zero JS domyślnie" opisuję szerzej przy okazji architektury wysp w Astro.

Czego Server Components same nie załatwią? Wszystkiego, co dzieje się interaktywnie po stronie klienta:

• Dynamiczne filtry, paginacja i auto-uzupełnianie — gdy użytkownik klika i odświeża fragment widoku bez przeładowania strony.
• Dane real-time — powiadomienia, czat, statystyki na żywo przez WebSockets albo SSE.
• Mutacje danych — formularze zapisujące zmiany na serwerze, które potem aktualizują widok.

W tych przypadkach wraca TanStack Query (albo SWR) po stronie klienta.

Najlepsze z obu światów — wzorzec prehydracji

Najmocniejsze podejście łączy oba modele: Server Component pobiera dane początkowe, a kliencki TanStack Query przejmuje je jako stan startowy i dalej zarządza odświeżaniem. Użytkownik dostaje gotowy widok natychmiast (dobre dla SEO i pierwszego renderu), a interaktywność i cache działają jak w czystej aplikacji klienckiej:

// app/users/[id]/page.tsx — Rzutowanie od Next.js z 15+ u rzutni z mocą od zapleczy Server Component
import { UserClient } from './user-client'
 
async function UserPage({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params
  const initialUser = await fetchUser(id)
  return <UserClient userId={id} initialData={initialUser} />
}

// app/users/[id]/user-client.tsx — Moduł rzucony u przeglądania u klienta "Client Component"
'use client'
 
import { useQuery } from '@tanstack/react-query'
 
export function UserClient({ userId, initialData }) {
  const { data: user } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetchUser(userId),
    initialData,
    staleTime: 60 * 1000,
  })
 
  return <Profile user={user} />
}

Dzięki temu zyskujesz zalety obu podejść: serwer renderuje gotowy HTML pod SEO i szybki pierwszy render, a klient dostaje inteligentny cache TanStack Query do odświeżania danych na żywo.

A co z klasycznym useEffect?

Ręczny fetch w useEffect ma dziś już bardzo wąskie zastosowanie. Są w zasadzie trzy sytuacje, w których nadal bywa właściwy:

1. Strumienie danych — WebSockets albo SSE, gdzie potrzebujesz utrzymać połączenie i subskrypcję, a nie wykonać pojedyncze pobranie. TanStack Query jest projektowany pod request-response, nie pod ciągły strumień.
2. Jednorazowe efekty po załadowaniu — proste akcje, które nie wymagają cache, retry ani inwalidacji.
3. Integracje z zewnętrznymi SDK — np. nasłuch zmian autoryzacji albo realtime z Firebase, gdzie podpinasz się pod cykl życia biblioteki.

Poza tymi przypadkami ręczny fetch w useEffect do pobierania danych aplikacji to antywzorzec — generuje wodospady, brak cache, brak retry i problemy z race conditions. Szczegółowo rozbieram to w artykule useEffect to prawie zawsze błąd — kiedy go naprawdę potrzebujesz, a kiedy nie.

Najczęstsze błędy z TanStack Query

W przeglądach kodu klientów te trzy pomyłki wracają najczęściej:

1. Niestabilny klucz zapytania. Jeśli do queryKey wstawisz wartość zmieniającą się przy każdym renderze (np. Date.now()), cache nigdy nie trafi — każde zapytanie ma inny klucz, więc TanStack pobiera dane od nowa za każdym razem.

// ŹLE — klucz zmienia się przy każdym renderze, cache bezużyteczny
useQuery({ queryKey: ['posts', Date.now()], queryFn: ... });
 
// DOBRZE — klucz oparty na realnych parametrach zapytania
useQuery({ queryKey: ['posts', { category, page }], queryFn: ... });

2. Tworzenie QueryClient wewnątrz komponentu. Jeśli instancja QueryClient powstaje przy każdym renderze (zamiast raz, w stabilnym miejscu), cały cache resetuje się na każdej zmianie drzewa. QueryClient twórz raz — w useState/module — i przekazuj do <QueryClientProvider>.

3. Trzymanie danych serwerowych w Zustand albo Reduxie. Ręczne kopiowanie danych z serwera do globalnego store to praca, którą TanStack Query wykonuje automatycznie — z cache, inwalidacją i odświeżaniem. Globalny store zostaw na stan czysto kliencki (UI, preferencje), a dane serwerowe powierz TanStack Query. Kiedy co wybrać do zarządzania stanem, rozbieram w artykule o Context, Zustand i URL state.