Chyba każdy kto korzystał z Reacta słyszał o Reduxie. Czy w 2020 roku warto korzystać z Reduxa? Czy dla mniejszych aplikacji, poziom skomplikowania wynikający z użycia Reduxa jest tylko dodatkową przeszkodą? Jeśli tak, to kiedy stwierdzić, że aplikacja jest wystarczająco duża i potrzebuje Reduxa? Spróbujmy odpowiedzieć na te pytania, a przy okazji sprawdzić alternatywy i poszukać dobrych wzorców, dzięki którym nasz kod będzie czytelny, łatwy w rozbudowie i utrzymaniu, nawet jeśli wrócimy do niego za jakiś czas. W końcu każdy może mieć z tym problem, nawet twórca Reduxa:
Czym jest Redux?
Redux jest miejscem, w którym przechowywany jest stan aplikacji. Czym z kolei jest ten stan? Stan aplikacji to innymi słowy warunki, w jakich znajduje się aplikacja w danej chwili. Najprościej wytłumaczyć to na przykładzie pojedynczego komponentu, np. menu.
Jak to się zaczęło?
Tworząc interfejsy musimy często określić w jakim stanie znaduje się dany komponent. Wyobraźmy sobie menu, które ma dwa stany: otwarte i zamknięte. W przeszłości nierzadko zdarzało się, że taki stan był przechowywany bezpośrednio w elemencie DOM reprezentującym dany komponent poprzez np. dodanie klasy:
<nav id="menu" class="is-open">(...)</nav>W przypadku wyspecjalizowanych, interaktywnych interfejsów, takie podejście może być źródłem licznych niedogodności. Wśród nich można wymienić m.in. utrudnione debugowanie, problemy wydajnościowe, imperatywny kod czy podatność na błędy.
Aby uczynić życie programistów JavaScript nieco znośniejszym, powstały liczne frameworki i biblioteki, rozwiązujące te i inne problemy. Jedną z takich bibliotek był React.
W React obok prostych komponenów, mamy do dyspozycji komponenty ze stanem. W odróżnieniu od tych pierwszych komponent taki oprócz danych wejściowych (this.props) może zarządzać swoim wewnętrznym stanem (this.state). Każda zmiana stanu komponentu skutkuje ponowym wyrenderowaniem treści na warstwie widoku.
No dobrze, ale co z tym wszystkim wspólnego ma Redux i dlaczego to tam mielibyśmy przechowywać stan aplikacji? React rozwiązuje problem stanu, ale tylko na poziomie komponentu. Co prawda do pewnego stopnia jesteśmy w stanie wynieść stan komponentu w górę, dzięki czemu kilka komponentów może odzwierciedlać te same zmiany. Nie zawsze jednak jest nam na rękę takie rozwiązanie. W skrajnych przypadkach programista byłby zmuszony do przepychania stanu przez wiele poziomów, a gdzieś na górze istniałby „boski komponent”, gromadzący stan różnych komponentów.
Tutaj na scenę wkracza Redux, który pełni rolę kontenera przechowującego stan aplikacji. W praktyce stan ten reprezentowany jest przez niemutowalną strukturę danych. W przypadku zmiany stanu któregoś z komponentów tworzona jest kopia stanu Reduxa wraz z uwzględnieniem zmiany, a zainteresowane komponenty powiadamiane są o zmianie.
Czy na pewno potrzebujesz Reduxa?
Warto mieć na uwadze, że Redux rozwiązuje pewne problemy, ale nie zdecydowanie nie jest lekarstwem na wszystko. Jeżeli nie wiesz czy powinieneś skorzystać z Reduxa – prawdopodobnie go nie potrzebujesz. Natomiast jeśli Twoja aplikacja posiada duże ilości zmieniających się często danych, widzisz, że wynoszenie stanu w górę już nie wystarcza, a Twój „boski komponent” ma zbyt wiele odpowiedzialności, to sygnał, że być może potrzebujesz narzędzia do pomocy w zarządzaniu stanem aplikacji. Pamiętaj jednak, że jak każde narzędzie czy framework Redux wymaga kompromisów.
W przypadku użycia Reduxa, należy liczyć się z następującymi konsekwencjami:
- stan aplikacji przechowywany jest w postaci obiektów i tablic
- zmiany opisywane są jako obiekty
- obsługa tych zmian odbywa się za pomocą czystych funkcji
Powyższe ograniczenia, nie są zazwyczaj wymagane do stworzenia aplikacji, wprowadzają większą złożoność i nadmiarowy kod dlatego są dodatkowym kosztem, który musisz ponieść.
Jeśli nie Redux to co?
Podsumowując, jeżeli czujesz, że stan Twojej aplikacji wymyka się spod kontroli oraz zauważyłeś pojawienie się „boskiego komponentu”, sprawdź jakie korzyści przyniesie Ci skorzystanie z Reduxa. Czy rozwiązują Twoje problemy? Przemyśl się co musiałbyś zmienić w swojej aplikacji i jak zmieni się proces dostarczania nowych funkcjonalności. Wykonaj PoC (Proof of Concept) i zastanów czy jest to opłacalne.
Czasami ciężko od samego początku określić czy dane rozwiązanie, framework czy biblioteka przyniesie nam oczekiwane korzyści, a prawidłowy wybór często jest wynikiem wcześniejszych doświadczeń. Dlatego w programowaniu pewne decyzje projektowe warto czasem odwlekać do samego końca, dzięki temu mamy więcej czasu na przemyślenie wszystkich za i przeciw.
Kontekst w React
Jest jeszcze jeden sposób na zarządzanie stanem w React, o którym nie wspominałem wcześniej. W sytuacji, gdy nie chcemy przekazywać danych z góry na dół jak to opisywałem wyżej, możemy wykorzystać specjalny komponent, nazwany Kontekstem, który umożliwia współdzielenie danych, bez potrzeby przekazywania ich w dół drzewa komponentów. Kiedy potrzebujemy dostępu do danych na wielu poziomach zagnieżdżenia, wówczas użycie Kontekstu wydaje się dobrym rozwiązaniem. Należy jednak mieć na uwadze, że nierozważne stosowanie Kontekstu utrudnia wielokrotne wykorzystanie komponentów, które się do niego odwołują.