SWR a React Query: wybór właściwego narzędzia

SWR ma rozmiar około 7 kB po kompresji gzip. React Query v5 ma około 13 kB po kompresji gzip. Różnica wynika z dodatkowych funkcji React Query: wstępnego pobierania zapytań, anulowania zapytań, bardziej szczegółowego cyklu życia zapytania oraz wbudowanych DevTools.

W aplikacjach, w których rozmiar ma duże znaczenie, lub w przypadku prostych wzorców pobierania i wyświetlania danych mniejszy rozmiar SWR jest istotną zaletą.

SWR ma prostsze i bardziej minimalistyczne API. Jeśli główną potrzebą jest pobieranie danych i wyświetlanie ich z automatyczną ponowną walidacją, SWR zapewnia eleganckie rozwiązanie przy bardzo małej ilości kodu dodatkowego.

SWR, rozwijany przez Vercel, wyjątkowo dobrze integruje się z Next.js, szczególnie przy łączeniu wstępnego pobierania za pomocą getServerSideProps lub getStaticProps z ponowną walidacją po stronie klienta z użyciem danych fallback.

Wstępnie pobrane dane należy przekazać do SWR za pomocą opcji fallback w SWRConfig albo opcji fallbackData w useSWR. SWR używa ich jako początkowej wartości pamięci podręcznej, eliminując migotanie przy pierwszym ładowaniu i jednocześnie umożliwiając ponowną walidację w tle.

Ten wzorzec jest zalecanym podejściem do pobierania danych w aplikacjach Next.js korzystających z Pages Router i Vercel.

React Query zapewnia dokładniejszą kontrolę nad cyklem życia zapytania: staleTime, gcTime (usuwanie nieużywanych danych z pamięci), refetchOnWindowFocus, liczba ponowień i opóźnienie między ponowieniami są konfigurowalne niezależnie. System mutacji z wywołaniami zwrotnymi onSuccess, onError i onSettled jest bardzo elastyczny.

React Query obsługuje również anulowanie zapytań za pomocą AbortSignal, co jest przydatne w interfejsach wyszukiwania podczas wpisywania.

useInfiniteQuery w React Query wraz z getNextPageParam został zaprojektowany specjalnie z myślą o przewijaniu nieskończonym i wzorcach ładowania kolejnych elementów. Zarządza logiką kursora stron i udostępnia obiekt pages w formie płaskiej lub strukturalnej.

SWR ma useSWRInfinite, które zapewnia podobne możliwości, ale oferuje nieco niższy poziom abstrakcji i wymaga bardziej ręcznego składania stron.

React Query obsługuje wstępne pobieranie zapytań po najechaniu kursorem lub przy zmianie trasy za pomocą queryClient.prefetchQuery. Dane znajdują się w pamięci podręcznej, zanim komponent zostanie zamontowany, co zapewnia natychmiastowe renderowanie.

SWR nie ma wbudowanego API do wstępnego pobierania poza danymi fallback z SSR. W przypadku wstępnego pobierania po najechaniu kursorem lepszym wyborem jest React Query.

React Query v5 uprościł API, sprawiając, że useQuery zwraca isPending zamiast isLoading, ujednolicając wzorce optymistycznych aktualizacji i poprawiając wnioskowanie typów w TypeScript. API v5 jest czystsze i bardziej spójne niż w poprzednich wersjach.

Jeśli rozważają Państwo użycie React Query, warto od razu wybrać wersję v5 zamiast uczyć się wersji v4 i później migrować.

SWR globalnie współdzieli wpisy pamięci podręcznej między komponentami na podstawie klucza, bez dodatkowej konfiguracji dostawcy poza SWRConfig używanym do ustawiania wartości domyślnych. React Query wymaga QueryClientProvider z instancją QueryClient.

W przypadku szybkiego prototypowania lub prostych aplikacji globalna pamięć podręczna SWR bez konfiguracji pozwala szybciej rozpocząć pracę. Jawnie skonfigurowany klient React Query lepiej sprawdza się w dużych aplikacjach o złożonych wymaganiach dotyczących buforowania.

SWR warto wybrać, gdy aplikacja jest przede wszystkim oparta na Next.js, wzorce pobierania danych są proste (pobierz–wyświetl–ponownie zweryfikuj), ważny jest minimalny rozmiar pakietu albo zespół przedkłada prostotę API nad zaawansowane funkcje.

SWR jest również dobrym wyborem, gdy chcą Państwo stopniowo wprowadzić bibliotekę do pobierania danych w istniejącej bazie kodu, bez przeprowadzania dużej migracji.

React Query warto wybrać, gdy potrzebne jest złożone zarządzanie stanem serwera: przewijanie nieskończone, wstępne pobieranie zapytań, strategie ponownego pobierania w tle, wieloetapowe zależności między zapytaniami lub szczegółowa kontrola czasu życia wpisów w pamięci podręcznej.

React Query ma również bardziej aktywny ekosystem rozszerzeń i DevTools, a jego queryClient można łatwiej testować w izolacji.

Niektóre zespoły używają obu rozwiązań: SWR do prostego pobierania pojedynczych zasobów w komponentach liściowych, a React Query na złożonych stronach korzystających z wielu zapytań i wstępnego pobierania. Jest to rzadkie, ale prawidłowe podejście, jeśli zespół biegle posługuje się oboma API.

Częściej zespoły wybierają jedno rozwiązanie i stosują je konsekwentnie w całej aplikacji, aby uniknąć przełączania kontekstu i dodatkowego narzutu związanego z dwiema zależnościami.

Jak w przybliżeniu wypada porównanie rozmiarów pakietów SWR i React Query?

SWR (~7 kB) jest prostszy, natywnie integruje się z Next.js i obsługuje większość wzorców pobierania i wyświetlania danych przy użyciu minimalnej ilości kodu. React Query (~13 kB) oferuje bogatszy zestaw funkcji: zapytania nieskończone, wstępne pobieranie, szczegółowe wywołania zwrotne cyklu życia i anulowanie zapytań.

SWR należy wybrać ze względu na prostotę i w projektach Next.js, a React Query — gdy wymagane jest złożone zarządzanie stanem serwera. Oba rozwiązania obsługują TypeScript, Suspense, SSR i wzorce działania offline.