Jak wdrożyliśmy SWR w projekcie i dlaczego go pokochaliśmy

Dlaczego SWR?

Ostatnio w SDH mieliśmy okazję rozwijać projekt w React z użyciem Redux/Toolkit. Tyle że, choć dane trzymaliśmy i pobieraliśmy ze store'a, w aplikacji nie było zaimplementowanego mechanizmu cache. A trzymanie dziesiątek odpowiedzi w stanie to, delikatnie mówiąc, średni pomysł. Szybko też zrobiło się zbyt łatwo, by pogubić się we wszystkich slice'ach stanu, mimo użycia Toolkit.  

Co więcej, na backend nie miało to wtedy żadnego pozytywnego wpływu. Przy tych ogromnych porcjach danych niektóre requesty trwały wieczność. A że UI aplikacji opierało się na długich listach elementów i niewielu operacjach CRUD, szybko stało się jasne, że przyda się jakiś cache. Wybór padł więc na SWR — bibliotekę stworzoną przez zespół Vercel (znany także z Next.js).

What is SWR?

Ok, lubisz czytać definicje? Mam nadzieję, że nie, bo ta będzie jedną z najkrótszych: ‘SWR to biblioteka React Hooks do zdalnego pobierania danych’. Tyle. Proste? Tak, ale zaraz pokażę, że SWR jest też bardzo potężny. A tak przy okazji: SWR to skrót od stale-while-revalidate. To już sporo mówi o działaniu. SWR najpierw zwraca dane z cache (stale), wysyła żądanie po aktualizację (revalidate), a następnie zwraca nowe dane.  Jak mówiłem — proste. 

Dlaczego pokochaliśmy SWR

Łatwo zauważyć, jak użycie SWR eliminuje problemy opisane na początku artykułu. Dzięki SWR:

• UI działał płynnie (po początkowych requestach) dzięki cache'owi danych 
• Usunęliśmy niemal wszystkie slice'y przechowujące dane z API i towarzyszącą im logikę
• Uprościliśmy proces rewalidacji danych po operacjach CRUD na kolekcjach
• Przyspieszyliśmy rozwój nowych funkcji zależnych od API

Jak więc wdrożyliśmy tę bibliotekę, żeby osiągnąć taki efekt? 

Jak działa SWR

Po krótkim czasie pracy z SWR okazało się, że jest naprawdę prosty i przyjazny. Chcesz wykonać request do API za pomocą SWR? Proszę bardzo:

Jest tu tylko jeden haczyk: fetcher. To po prostu Twoja własna funkcja do pobierania danych. Aplikacja, nad którą pracowaliśmy, miała już skonfigurowany axios z pełnym configiem (interceptors, headers, base URL itd.), więc po prostu opakowaliśmy naszą instancję axios w taki sposób, by dostać własny fetcher:

Dzięki temu cały hook może wyglądać tak prosto (w tym przykładzie pomińmy obsługę błędów):

I... to wszystko! Stworzyliśmy hook do pobierania danych z API korzystając ze wszystkich dobrodziejstw SWR. Za każdym razem, gdy wywołasz ten hook, najpierw zwróci wcześniej pobrane dane (jeśli są), a dopiero potem zrevaliduje i zwróci nową kolekcję.

SWR out of the box ma garść prekonfigurowanych opcji (wszystkie są wymienione tutaj), dzięki którym praca z nim to bułka z masłem. Warto wspomnieć o ulubionej opcji: dedupingInterval.

Typowy scenariusz: pobierasz dane w jednym komponencie, rozwijasz go dalej, komponenty potomne zaczynają się rozrastać, aż w końcu dziecko 4. poziomu potrzebuje tych danych. Jak je tam dostarczyć bez większego wysiłku i bez powielania requestów? Spokojnie: po prostu ponownie użyj hooka SWR... Deduping interval nie pozwoli wykonać tego samego requestu ponownie przez określony czas (domyślnie 2 sekundy). W sam raz.

„Ale jeśli wywołam endpoint i zwróci te same dane co wcześniej, mój komponent i tak się przerysuje”. Nie — SWR stosuje głębokie porównanie, więc przerysowanie (rerender) nastąpi tylko wtedy, gdy dane faktycznie się zmienią. Funkcję porównującą możesz oczywiście dostosować. 

Mutacje danych

Możesz powiedzieć, że pobierać (GET) dane jest zawsze łatwo — a co z mutacjami? To na pewno bardziej skomplikowane. Niekoniecznie: mutacje nie muszą być koszmarem, a mnie zaskoczyło, jak prosto mutuje się dane w SWR (po wcześniejszych przygodach z Apollo). Oto przykład z życia:

W tym przykładzie mutate to funkcja importowana z SWR, a /users to klucz, który nadaliśmy w hooku useUsers (nie musi to być URL endpointu — klucz i URL możesz przekazać osobno).

Jeśli chcesz trzymać w cache i aktualizować pojedynczą encję (obiekt) pobraną z większej kolekcji, po prostu zmutuj ją po jej kluczu, na przykład tak:

Brzmi zbyt prosto? To jest proste. Spróbuj sam, a być może zaoszczędzisz sporo czasu na pisaniu rozbudowanej logiki w Reduxie i debugowaniu wywołań API.

Integracje SWR

Jak widać, wdrożenie SWR jest proste; dodając kilka smaczków, łatwo wynieść powyższe przykłady na wyższy, bardziej abstrakcyjny poziom. Oczywiście, SWR na tym się nie kończy — dostępnych jest mnóstwo opcji i integracji:

integracja z GraphQL

obsługa błędów z mechanizmem ponowień (retry)

automatyczna rewalidacja

obsługa paginacji (także dla infinite loading)

prefetching danych

i wiele innych (dokumentacja)

Praca z SWR była dla nas naprawdę świetna i na pewno rozważymy jego użycie w kolejnych projektach. Jeśli chcesz dowiedzieć się więcej o tej bibliotece, odwiedź ich oficjalną stronę z dokumentacją, konfiguracjami i przykładami tutaj.

Miłego kodowania!