Unstated Next czy Redux – co lepsze do zarządzania stanem w React?
Zarządzanie stanem w React, mimo że jest kluczowym aspektem tworzenia aplikacji i istnieje mnóstwo przydatnych narzędzi i bibliotek, wciąż nie zostało rozwiązane, ani nawet się do tego nie zbliżyło. Przez lata większość deweloperów pozostała przy Reduxie, ale stale rosnąca liczba nowych bibliotek do zarządzania stanem sugeruje, że jest tu jeszcze sporo miejsca na ulepszenia. React sam w sobie wprowadził dużo wsparcia, jak Context API czy Hooks. Choć początkowo wielu uznało to za „koniec” Reduxa, rzeczywistość okazała się zupełnie inna – Redux nadal pozostaje najpowszechniej używanym narzędziem do zarządzania stanem.
Wszyscy używają Redux
Redux był wielokrotnie krytykowany, a mimo to pozostaje najczęściej wykorzystywanym narzędziem do zarządzania stanem od czasu, gdy wyszedł zwycięsko z tzw. wojen fluxowych – okresu, kiedy różne biblioteki oparte na architekturze Flux Facebooka rywalizowały o miano najlepszego rozwiązania do zarządzania stanem w React. To właśnie Redux przyćmił inne biblioteki. Z biegiem lat jednak pojawiło się wiele skarg, głównie dotyczących ilości boilerplate’u i problemów z wydajnością – Redux nie był tworzony z myślą o szybkości czy prostocie, lecz o przewidywalności, czyli ułatwieniu śledzenia aktualizacji stanu.
W rzeczywistości wiele zarzutów wynika z jego powszechnego zastosowania, prowadzącego do nadużyć. Ponieważ Redux skupia się na łatwym śledzeniu zmian stanu, nie każda aplikacja go potrzebuje (a czasami lepszym wyborem byłaby inna biblioteka). Dodatkowo, przez podejście „single source of truth”, często wszystko trafia do Reduxa, co wcale nie jest optymalnym rozwiązaniem. Jako że Redux stał się domyślną opcją dla zarządzania stanem, jesteśmy niejako zmuszeni z niego korzystać, a to wiąże się z krzywą uczenia się i pewnymi problemami, które nie każdemu odpowiadają, zwłaszcza osobom przyzwyczajonym do programowania obiektowego.
Jak Unstated Next wypada lepiej?
Niektóre nowsze biblioteki postanowiły w pełni wykorzystać nowe możliwości oferowane przez React. Jedną z nich jest Unstated Next, stworzona praktycznie na bazie React Context API. To duchowy następca Unstated, skupiający się przede wszystkim na zachowaniu maksymalnej prostoty i lekkości. Jak to osiąga? Po prostu wykorzystuje React i dostępne w nim narzędzia (Hooks, Context) do maksimum, dodając jednocześnie przydatne Containery. Są one jak komponenty, ale służą tylko do przechowywania stanu. Wystarczy umieścić kawałek stanu w Containerze, inne komponenty mogą subskrybować jego zmiany, a każda modyfikacja stanu powoduje rerender komponentów korzystających z tego Container'a. Porównajmy to z Reduxem:
- mniejszy i szybszy: Unstated Next w zasadzie opiera się na wbudowanych funkcjonalnościach Reacta i komponentyzacji wszystkiego, co sprawia, że jest wielokrotnie mniejszy i znacząco szybszy niż Redux.
- o wiele prostszy: Prawie nie ma tu krzywej uczenia – jeśli znasz
useState,useContexti własne Hooki (a jeśli używasz React, to raczej umiesz ich używać), opanowanie Unstated Next zajmie ci najwyżej 5 minut. Dodatkowo Containery jeszcze bardziej wszystko upraszczają. - napisany w Typescript: wsparcie dla TypeScript out-of-the-box oznacza sprawdzanie typów i mniej potrzeby testowania
- oparty na containerach: To oznacza mniej boilerplate’u i po prostu poleganie na Context API pod spodem. Pozwala też dowolnie łączyć się z każdą biblioteką reactową po jednym komponencie na raz.
Nadużycie nie jest dobrym pomysłem
Wielu spodziewało się, że dodatki w postaci Hooków sprawią, że Redux stanie się przestarzały (albo po prostu z niecierpliwością czekało, by się go pozbyć). Pomysł był taki, że Hooki useContext i useReducer zostaną wykorzystane do zarządzania stanem zamiast globalnego kontenera stanu, jakim jest Redux. Tak się jednak nie stało i Redux pozostaje głównym graczem w zarządzaniu stanem. Co więcej, doczekał się teraz własnego Hook API, korzystając z tego, co wprowadził React. Mimo licznych krytyk wymienionych wyżej, Redux nie jest zły, jest po prostu nadużywany i zbyt mocno na nim polegamy z powodu jego długotrwałej dominacji. Zamiast narzekać na konieczność korzystania z Reduxa, powinniśmy raczej skupić się na tym, kiedy warto sięgnąć po alternatywy, jak Unstated Next, które mogą lepiej pasować do danego projektu. Ekosystem zarządzania stanem w React stale się zmienia, więc nie musimy porzucać jednego rozwiązania na rzecz drugiego. Możemy dalej opierać się na Reduxie, gdy jest to potrzebne, a w innych przypadkach próbować nowszych narzędzi, które mogą być lepsze w konkretnych sytuacjach. Dodatkowo, choć Hooki nie uczyniły Reduxa przestarzałym, zawsze może pojawić się coś nowego, więc warto mieć na to oko!