Podstawowe pojęcia SWR: stale-while-revalidate

SWR to skrót od Stale-While-Revalidate — strategii cache'owania HTTP zdefiniowanej w RFC 5861. Strategia polega na natychmiastowym udostępnieniu użytkownikowi nieaktualnych (zbuforowanych) danych, a następnie ponownym zweryfikowaniu ich w tle i zaktualizowaniu interfejsu po nadejściu świeżych danych.

To podejście stawia na odczuwaną wydajność: użytkownicy widzą dane natychmiast, zamiast czekać na pełną podróż w obie strony przez sieć.

Przy tradycyjnych wzorcach ładowania użytkownicy widzą wskaźnik ładowania przy każdej nawigacji. W przypadku SWR od razu widzą ostatnio znane dane, a interfejs jest dyskretnie aktualizowany w tle, jeśli dane uległy zmianie.

Dzięki temu aplikacje wydają się znacznie szybsze, a obciążenie poznawcze związane ze stanami ładowania jest mniejsze.

SWR automatycznie przeprowadza rewalidację danych, gdy: okno przeglądarki ponownie zyskuje fokus (użytkownik przełącza karty i wraca), połączenie sieciowe zostaje przywrócone po pracy offline, wywołano mutate(), lub uruchamia się timer refreshInterval o konfigurowalnym interwale.

Te automatyczne wyzwalacze zapewniają aktualność danych bez konieczności ręcznego zarządzania logiką ponownego pobierania przez programistę.

Klucz SWR może znajdować się w jednym z kilku stanów: loading (brak danych w pamięci podręcznej, trwa pierwsze pobieranie), revalidating (dane są dostępne w pamięci podręcznej, trwa odświeżanie w tle), error (żądanie zakończyło się niepowodzeniem) lub success (dostępne są świeże dane).

Zrozumienie tych stanów pomaga budować poprawne szkielety ładowania i interfejsy obsługi błędów.

SWR utrzymuje globalną pamięć podręczną w pamięci operacyjnej, indeksowaną kluczem żądania (zwykle ciągiem URL). Każdy komponent, który żąda danych za pomocą tego samego klucza, otrzymuje tę samą wartość z pamięci podręcznej i uczestniczy w tym samym cyklu rewalidacji.

Ta automatyczna deduplikacja oznacza, że 10 komponentów może wywołać useSWR z tym samym kluczem, a mimo to zostanie wykonane tylko jedno żądanie sieciowe.

SWR oddziela logikę zarządzania pamięcią podręczną od faktycznego pobierania danych. Należy dostarczyć funkcję fetcher: funkcję asynchroniczną, która przyjmuje klucz i zwraca dane.

Funkcję fetcher można wymienić: można użyć fetch, axios, graphql-request lub dowolnego asynchronicznego źródła danych. SWR obsługuje cache'owanie i rewalidację niezależnie od sposobu działania funkcji fetcher.

Należy opakować aplikację w SWRConfig z właściwością value zawierającą funkcję fetcher: value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}. Każde wywołanie useSWR, w którym pominięto argument fetcher, korzysta z tej globalnej wartości domyślnej.

Dzięki temu konfiguracja API (bazowy URL, nagłówki uwierzytelniania) jest scentralizowana w jednym miejscu i nie trzeba jej powtarzać przy każdym wywołaniu hooka.

Klasyczny wzorzec wykorzystuje useEffect + useState do ręcznego zarządzania stanami ładowania, danych i błędów. SWR zastępuje to wszystko pojedynczym wywołaniem hooka, który automatycznie obsługuje cache'owanie, deduplikację, odświeżanie w tle i ponawianie żądań po błędach.

Redukcja ilości kodu jest znacząca: typowy komponent pobierający dane skraca się z ponad 20 wierszy do 3.

Klucz jednoznacznie identyfikuje żądanie. W prostych przypadkach należy użyć ciągu URL. W przypadku żądań sparametryzowanych należy użyć klucza tablicowego: [url, params], gdzie params jest stabilnym obiektem lub ciągiem znaków. null wyłącza żądanie.

Dobry projekt kluczy gwarantuje, że powiązane żądania współdzielą wpisy pamięci podręcznej, a niezależne żądania nie powodują kolizji.

SWR inteligentnie zarządza rewalidacją: dedupingInterval (domyślnie 2 sekundy) zapobiega jednoczesnemu uruchomieniu wielu rewalidacji, gdy wiele komponentów zostanie zamontowanych naraz. W ramach okna deduplikacji dla każdego klucza wykonywane jest tylko jedno żądanie.

Zapobiega to problemom typu thundering herd, często spotykanym w dużych drzewach komponentów, w których wiele komponentów pobiera te same dane.

SWR jest tworzony przez Vercel, firmę stojącą za Next.js, a integracja przebiega bezproblemowo. getServerSideProps lub getStaticProps mogą wstępnie pobrać dane, a SWR przeprowadza hydratację po stronie klienta na podstawie tej wstępnie pobranej wartości.

Dzięki temu otrzymujemy początkowy kod HTML renderowany po stronie serwera z automatyczną rewalidacją po stronie klienta podczas montowania, łącząc najlepsze cechy SSR i SWR.

Co z poniższych elementów domyślnie NIE wyzwala rewalidacji SWR?

SWR implementuje strategię Stale-While-Revalidate: natychmiast udostępnia dane z pamięci podręcznej, przeprowadza rewalidację w tle i aktualizuje interfejs po uzyskaniu świeżych danych. Rewalidacja jest uruchamiana przy odzyskaniu fokusu, ponownym połączeniu z siecią, wywołaniu mutate oraz podczas odpytywania. Globalna pamięć podręczna deduplikuje żądania między komponentami, a funkcję fetcher można w pełni wymienić.

Ten model znacznie upraszcza kod pobierający dane, zapewniając jednocześnie większą odczuwaną wydajność.