Stan zakresu według czasu trwania: Kiedy React Portal rzeczywiście potrzebuje globalnego sklepu danych
Naucz się określać, gdzie powinien znajdować się stan portalu React na podstawie jego właściciela i czasu trwania, dlaczego globalne magazyny powodują błędy przy czyszczeniu, oraz w jakich przypadkach rzeczywiście opłaca się użyć Redux lub Zustand.
Zespoły tworzące portale wewnętrzne często rozpoczynają dyskusję od pytania „Redux czy Zustand?”. Bardziej przydatne pierwsze pytanie brzmi: które elementy stanu faktycznie muszą być globalne? Ten artykuł pokazuje, jak klasyfikować stan portalu według tego, kto nim zarządza i jak długo powinien istnieć, dlaczego przechowywanie stanu krótkotrwałego w globalnym magazynie powoduje ciągły napływ błędów związanych z jego usuwaniem, oraz kiedy użycie globalnej biblioteki jest właściwym rozwiązaniem.
Większość stanu portalu ma krótki czas trwania
Portale zazwyczaj składają się z odrębnych procesów pracy. Użytkownik otwiera stronę, wyszukuje lub edytuje coś, kończy zadanie i przechodzi do innej części aplikacji. Wartości form, filtry, wybrane wiersze tabeli, aktywna karta oraz to, czy jest otwarty moduł interaktywny, wszystko to należy do danej strony lub procesu pracy. Rzadko muszą one być przechowywane między kilkoma niepowiązanymi trasami.
Tylko niewielka grupa danych jest rzeczywiście dostępna w całej aplikacji:
- zalogowany użytkownik;
- stan autoryzacji i uprawnienia;
- bieżąca organizacja lub tenant;
- wybrane tematy i ustawienia językowe.
Prawie wszystko inne powinno pozostać związane z funkcją, która je definiuje.
Globalne magazyny zamieniają czas trwania aplikacji w zadanie czyszczenia
Gdy przechowujesz tymczasowy stan w Redux, Zustand, MobX lub innym globalnym magazynie, ten przetrwa ekran, który go stworzył. Wtedy potrzebujesz dodatkowego kodu, aby go sformatować przy przeglądaniu innych ekranów, po wysłaniu danych, przy wylogowaniu, gdy zmienia się tenant oraz przy każdym innym wyjściu z aplikacji. Jeśli pominiesz jakiś taki przypadek, użytkownik wróci na ekran z przestarzałymi filtrami, starymi wyborami lub niekompletnymi danymi z poprzedniej wizyty. Takie błędy są trudne do odtworzenia, ponieważ zależą od dokładnej kolejności ekranów, które odwiedził użytkownik.
Zasada, której należy przestrzegać, jest prosta: jeśli stan globalny musi być ciągle oczyszczany, aby zachowywał się jak stan lokalny, to prawdopodobnie od samego początku powinien być lokalny.
Wybierz najwęższy możliwy zakres
Dopasuj każdą część stanu do najwęższego narzędzia, które obejmuje cały okres jego istnienia:
- stan komponentu dla zachowań interfejsu dotyczących pojedynczego komponentu;
- React Context dla stanu udostępnianego pomiędzy poszczególnymi funkcjami lub grupą powiązanych tras;
- parametry wyszukiwania w URL dla filtrów, paginacji oraz innego stanu nawigacyjnego, co umożliwia również udostępnianie widoków i zachowanie ich po odświeżeniu;
- bibliotekę do zarządzania stanem serwera, taką jak TanStack Query, dla danych pobieranych z backendu, ponieważ jej zadaniem jest cacheowanie i unieważnianie danych, a nie Twojego sklepu stanu;
- sklep stanu globalny tylko wtedy, gdy chodzi o stan klienta, który rzeczywiście dotyczy całej aplikacji.
Kontekst na poziomie ścieżki zasługuje na osobne wzmiankę. Gdy umieścisz dostawcę wokół grupy ścieżek, opuszczenie tej grupy powoduje odłączenie dostawcy, a jego stan automatycznie znika. Cykl życia komponentu w React zajmuje się czyszczeniem, które inaczej musiałbyś napisać ręcznie. Jeśli motywacją do użycia magazynu stanu jest rzeczywiście przekazywanie właściwości przez wiele warstw, to jest to odrębny problem z prostszymi rozwiązaniami, omówiony w dlaczego przekazywanie właściwości przez wiele warstw nie jest powodem do instalacji Redux lub Zustand.
Kiedy globalny magazyn stanu ma sens
Redux, Zustand oraz podobne biblioteki są właściwym wyborem, gdy stan ma celowo przetrwać na niepowiązanych ze sobą ekranach. Typowe przypadki to:
- wózki zakupowe;
- skomplikowane procesy płatności obejmujące kilka stron;
- projekty, które muszą być zachowane;
- aplikacje typu offline-first;
- systemy komunikacji lub powiadamień w całej aplikacji;
- funkcje cofania i ponownego wykonania działań;
- funkcje w czasie rzeczywistym, gdzie stan klienta musi być skoordynowany;
- skomplikowane procesy pracy z wieloma wzajemnie powiązanymi przejściami stanów.
W takich sytuacjach centralizowany stan rozwiązuje rzeczywisty problem, zamiast go tworzyć.
Główne wnioski
- Niech przed wyborem żadnej biblioteki zostanie określona odpowiedzialność za zarządzanie stanem oraz jego czas trwania.
- Stan należący do konkretnego procesu pracy powinien zniknąć wraz z tym procesem, najlepiej poprzez jego wyłączenie, a nie ręczne sformatowanie.
- Dane serwera należy przechowywać w bibliotece do wyszukiwania, a stan nawigacji – w adreście URL.
- Zarezerwuj globalny magazyn dla stanu, który cała aplikacja celowo dzieli się między sobą na przestrzeni czasu; umiejętność określenia, kiedy go nie używać, jest częścią dobrej architektury.
Pozycje pokrewne
- Ułożenie stanu w aplikacji strimującej w React: Context, Redux Toolkit i RTK Query — Prześledź frontend aplikacji do streamowania wideo, od mechanizmu prop drilling po zagnieżdżone provider’y, aż po komponenty Redux Toolkit slices i RTK Query, i dowiedz się, jaki rodzaj stanu pasuje do której narzędzia.
- Mechanizm prop drilling to nie jest powód do instalacji Redux czy Zustand — Przetestuj cztery powszechne powody dodawania biblioteki do zarządzania stanem w kontekście działającego kodu React: użycie Context do mechanizmu prop drilling, funkcje useState i useSyncExternalStore oraz koszt ponownego renderowania Context.