Podczas tworzenia aplikacji webowych dużą rolę odgrywa przepływ danych. Istnieje kilka podejść mających go umożliwić i ułatwić. Jednym z pierwszych powszechnie stosowanych jest wzorzec publish-subscribe. Umożliwia on jednemu komponentowi subskrypcję do zdarzeń drugiego komponentu, jednocześnie wymuszając pewien stopień enkapsulacji funkcjonalności obu z nich.
Szczególnym przykładem zastosowania tego wzorca jest system zdarzeń używany przez przeglądarki. Dlatego też to właśnie tzw. pub/sub był głównym wyborem w pierwszych frameworkach w JavaScripcie.
Niestety, takie rozwiązanie ma swoje wady. Wysłanie kilku zdarzeń jednocześnie może mieć niedeterministyczną kolejność wykonania, co wraz z rozwojem aplikacji może powodować problem skalowania zależności, prowadzący do chaosu w kodzie i wielu błędów. Dodatkowo, zdarzenia z reguły odpowiadają za konkretne, bardzo granularne akcje, co sprawia, że utrzymanie sensownego cyklu życia komponentów jest bardzo ciężkie i pracochłonne.
Wraz z rozwojem bogatego ekosystemu webowego powstała też potrzeba stworzenia sensowniejszego wzorca zarządzania stanem w aplikacjach. Potrzebie tej wyszedł naprzeciw Flux. W artykule przybliżę, czym jest Flux, z jakimi potencjalnymi problemami możemy się spotkać podczas wykorzystywania rozwiązania, a także krótko opiszę istniejące implementacje.
Flux – czym jest i jak działa?
Flux to opracowany przez Facebooka wzorzec architektury zarządzania stanem aplikacji, który miał rozwiązać wymienione wyżej problemy. Ciekawostką jest to, że wywodzi się z uporczywego błędu z licznikiem powiadomień w czacie Facebooka, którego naprawa wymagała zmiany architektury całego serwisu. Zainteresowanych odsyłam do prelekcji, w której opisano ten problem: Hacker Way: Rethinking Web App Development at Facebook.
Rdzeń tego podejścia stanowią:
- niemutowalność (ang. immutability) – wszelkie modyfikacje stanu powinny wiązać się z utworzeniem nowego obiektu np. poprzez kopiowanie. Pozwala to aplikacji łatwo wykryć zaistniałe zmiany i odpowiednio na nie zareagować.
- jednokierunkowy przepływ danych (ang. unidirectional data flow) – dane mogą być przekazywane tylko w jedną stronę, w dół drzewa komponentów. Zapewnia to większą przewidywalność zachowania aplikacji, co dodatkowo wpływa na łatwość w rozwiązywaniu problemów z kodem aplikacji.
System zarządzania stanem w architekturze Flux opiera się o następujące konstrukcje:
- magazyn (ang. store) – najważniejszy element całego systemu. To on jest jedynym źródłem prawdy o przechowywanych danych i to on nimi zarządza. Aplikacja może posiadać wiele magazynów – z reguły odpowiadających za poszczególne części aplikacji np. UserStore itd. Po zinterpretowaniu akcji wysłanej przez dispatcher, magazyn emituje zdarzenie zmiany do zasubskrybowanych widoków.
- akcje – obiekty opisujące, jaka zmiana stanu ma zajść. Zazwyczaj zawierają typ oraz ładunek (ang. payload). Akcje są rodzajem zdarzeń, które po dotarciu do magazynu informują go o tym, którą czynność powinien wykonać.
- widoki (ang. views) – elementy interfejsu, które mogą zasubskrybować się do magazynu i dzięki temu reagować na wyemitowane przez niego zmiany danych. Zazwyczaj dzieli się je na widoki-kontenery (łączące się z magazynami) oraz widoki prezentacyjne, które działają tylko na danych przekazanych do nich przez nadrzędne komponenty.
- dispatcher – pojedynczy obiekt odpowiedzialny za rozgłaszanie akcji z widoków do wszystkich zasubskrybowanych magazynów.
Dodatkowo, by ułatwić tworzenie i wysyłanie akcji, przyjęto, że dobrą praktyką jest tworzenie tzw. kreatorów akcji (ang. action creators), czyli funkcji, które zwracają odpowiednio przygotowane obiekty akcji, gotowe do przekazania dispatcherowi.
Mechanizm zmiany stanu przedstawia się następująco:
- widok wysyła akcję (utworzoną np. poprzez kreator akcji) do dispatchera,
- dispatcher rozgłasza akcję do wszystkich zarejestrowanych magazynów,
- magazyn, który implementuje otrzymaną akcję, przetwarza swój stan w odpowiedni sposób i rozsyła tę zmianę do widoków, które się do niego zasubskrybowały,
- widoki renderują lub w inny sposób przetwarzają otrzymane dane.
Takie podejście umożliwia kontrolowalne i modularne podejście do zarządzania danymi, które pozwala odseparować dane i logikę poszczególnych domen aplikacji. Dodatkowo, centralnie sterowany mechanizm daje sposobność, aby w łatwy sposób zadbać o reaktywność przepływu danych.
Flux zapewnia jednokierunkowy przepływ danych poprzez użycie globalnego systemu zarządzania wiadomościami, co wiąże się z przewidywalnością wykonania kodu i w rezultacie przekłada się na łatwość w pisaniu i utrzymaniu aplikacji. Komponenty, dzięki oparciu się o dane z magazynu, nie muszą już subskrybować się do konkretnych zdarzeń wysyłanych przez inne komponenty. Ich zadaniem jest od teraz tylko i wyłącznie interpretacja zmian danych dostarczonych przez magazyn i wykonywanie odpowiedniej logiki.
Potencjalne problemy
Niestety, Flux posiada także wady. Największą z nich jest poziom skomplikowania takiej architektury, a co za tym idzie – trudność w jej opanowaniu. Jednocześnie, złe jej użycie może jeszcze bardziej zagmatwać kod i utrudnić naprawianie problemów. Bardzo łatwo spotkać kod, który źle lub nadmiernie wykorzystuje architekturę Flux.
Dodatkowo, z reguły implementacja tej architektury, korzystając z jednego z wielu istniejących frameworków, wymaga masy czasu i pracy. Często dla jednej funkcjonalności należy napisać mnóstwo linii kodu, by obsłużyć nawet najprostszą interakcję z magazynami.
Flux nie jest złotym środkiem w aplikacjach webowych i nie zawsze jest konieczny. O ile samo to podejście „naprawiło” świat aplikacji webowych, tak w większości przypadków nie jest wymagane. Na wzorcu tym skorzystają głównie duże projekty, których domeny krzyżują się w wielu komponentach i próba przekazywania do nich danych domenowych w tradycyjny sposób zakończyłaby się ostatecznie katastrofą.
Implementacje
Sam Flux kończy niedługo 10 lat. Nic więc dziwnego, że powstało wiele niezależnych implementacji, które bazują i często rozwijają koncepcje opisane powyżej. Najpopularniejsze z nich to:
- Redux – według niektórych wzorcowa implementacja Fluxa, używana przeważnie w tandemie z Reactem przy użyciu wrappera react-redux.
- NgRx – w wielu przypadkach uważana za standard w aplikacjach tworzonych w Angularze. Cechą charakterystyczną jest wykorzystanie RxJS i tzw. reaktywnych rozszerzeń do kontroli zmian stanu.
- Pinia – oficjalnie polecana przez twórców Vue implementacja architektury Flux dla tego frameworka.
Innych implementacji jest mnóstwo, a kolejne lata przyniosą pewnie ich jeszcze więcej.
Podsumowanie
Koncepcja architektury Flux odmieniła front-end i dzięki swoim zaletom na pewno zostanie z nami na długo. Tylko czas pokaże, czy za kilka lat kolejny uporczywy błąd w jakimś popularnym serwisie przyniesie drugą taką rewolucję.
***
Jeśli interesują Cię inne artykuły napisane przez ekspertów z Centrum Kompetencyjnego Digital, polecić możemy m.in.: More reactive Angular, Podejście do refaktoryzacji w projekcie ze starymi technologiami, .NET i Raspberry Pi – możliwości wykorzystania platformy na mikrokomputerach, Local Variable Type Inference (var) w Java 10 oraz Collection interface – co warto wiedzieć?
Zostaw komentarz