Będzie coś o Reduxie.

Redux. Biblioteka, która sporo namieszała w świecie frontendu.

Czemu? Co w niej takiego jest?

W zasadzie nic czego nie byłoby gdzie indziej:

• kolejna biblioteka realizująca architekturę flux polecaną dla Reacta
  
• kolejna biblioteka do emitowania i nasłuchiwania eventów (powszechnie używany był wcześniej choćby EventEmitter z NodeJS)
  
• kolejna implementacja wzorca CQRS
  
• kolejna biblioteka, która wykorzystuje koncepcję reducerów z programowania funkcyjnego
  
• kolejna implementacja event sourcingu (czy może raczej biblioteka, w której można w bardzo prosty sposób zastosować event sourcing). (
  

Czemu jednak zdobyła taką popularność?

• Szczęśliwy traf i fajne demo.
  
• Fakt, że powstało to w ekosystemie Reacta, który był gorącą biblioteką w 2015
  
• Prostota. Redux jest prosty w użyciu, opiera się na prostych zasadach (jeden stan na całą aplikację, wysyłanie komunikatów przez funkcję dispatch, zmiana stanu w reducerach, uaktualnienie komponentów o dane).
  
• Przemyślana architektura:
  
  • Mimo, że jest to biblioteka, która powstała jako tool do Reacta, sam Redux nie jest od niego zależny - co oznacza, że Reduxa można używać z dowolnym frameworkiem. Niektórzy go np. do Angulara używają
  • łatwa możliwość rozszerzania funkcjonalności o np. dodatkowe reducery, dodatkowe middleware itp. jest to elastyczne
• Potęga wzorców - samo użycie wzorców znanych z programowania funkcyjnego, choćby niezmienność (immutability)danych oraz połączenie to z eventami sprawia, że rzeczy typu "cofanie w czasie" są banalne (jednak zanim zaczniecie ogłaszać odkrycie Ameryki, uświadomcie sobie że to żadna nowość. Ludzie tak od conajmniej kilkunastu lat robią. Wygooglujcie sobie "event sourcing". W zasadzie Greg Young twierdzi, że event sourcing ma kilka tysięcy lat, ale nie weryfikowałem tej informacji).
  
• Zaangażowanie twórcy Reduxa (Dana Abramova), który jest dość aktywny choćby na Twitterze i bada problem z wielu stron (nawet napisał artykuł pod tytułem You Might Not Need Redux
  
• Ekosystem, choćby fakt, że autor stworzył własne DevToolsy do swojej biblioteki(!).
  

No dobra, czy zatem to znaczy, że Redux jest najlepszą biblioteką i jeśli czegoś używać to Reduxa?

Wydaje mi się, że to trochę już inne pytanie. Wyjaśniłem skąd się wzięła (wg mnie oczywiście) popularność tej biblioteki, co nie znaczy, że uważam ją za najlepsze rozwiązanie w każdej sytuacji. O ile generalnie lubię Reduxa, to jednak pisząc coś większego w nim mam poczucie, że jednak nie do końca jest to odpowiednie:

• Nie wiadomo co zrobić ze skutkami ubocznymi, np. wywołanie funkcji ajax, odwoływanie się do zewnętrznych API. W reducerach zgodnie z zasadami nie powinno być żadnych skutków ubocznych. Można więc umieścić je w middleware, można stworzyć sobie action creatory i tam umieścić, można w funkcji subscribe, można w samym komponencie React (jeśli się korzysta z Reacta) - ale tak czy siak skutki uboczne to pięta achillesowa Reduxa. Nie jest to przemyślane, o czym świadczy choćby fakt powstawania takich bibliotek jak Redux-Saga.
  
• Tak samo asynchroniczność nie jest przemyślana. Nie będę się o tym rozpisywał więcej, bo to co napisałem o skutkach ubocznych można odnieść również do wysyłania asynchronicznych akcji. Mam wrażenie, że to jedna wielka partyzantka.
  
• samo programowanie niezmiennych(niemutowalnych) struktur w JavaScript na większą skalę jest dość niewygodne - chyba, że się korzysta np. z ImmutableJS, ale to dodatkowa biblioteka do instalacji.
  
• nie ma pewnych rzeczy out of the box, np. kompozycja kilku akcji - albo akcje, które wywołują inne akcje (chyba, że coś się zmieniło albo po prostu nie znam sposobu, w jaki można to łatwo osiągnąć w uporządkowany sposób - jeśli tak, to napiszcie w komentarzu).
  
• Brakuje mi przestrzeni nazw dla akcji.
  
• Nasłuchiwania konkretnych akcji (z możliwością użycia gwiazdki jako wildcarda czy regexpów) też mi brakuje.
  
• Mając złożoną aplikację można łatwo się zagubić - ileś reducerów, ileś rodzajów akcji, ileś warstw middleware - plus rzeczy, których nie trzeba robić, ale wiele osób zwyczajowo robi - np. action creatory. To wszystko sprawia, że przy większym projekcie sama infrastruktura związana z obsługą Reduxa się rozrasta. Ciężko potem nadążyć za tym, co się w projekcie dzieje.
  

Czy to znaczy, że Redux jest słaby?

Też nie do końca. Piszę swoje odczucia: używając Reduxa mam poczucie, że używam fajnej biblioteki, ale jednak nie do końca dopasowanej do potrzeb realnych projektów. Mam wrażenie, że Redux pomimo swojej fajności, jest zaledwie pewnego rodzaju proof of concept, i że powinien albo samemu wyewoluować w lepszą bibliotekę, albo powinien stać się inspiracją do napisania lepszej biblioteki przez kogoś.


Podsumowując - Redux to prosta biblioteka, która jednak w obecnej postaci wg mnie raczej nadaje się do mniejszych projektów niż jako całościowe rozwiązanie do złożonych aplikacji.


No i taki disclaimer - jestem trochę do tyłu: nie używałem Redux-Saga (biblioteka, która podobno pomaga obsługiwać te kłopotliwe skutki uboczne w Redux), nie używałem Mobx (alternatywa do Reduxa, która ostatnio robi się populana) nie znam też ostatnich dobrych praktyk reduksowych (które się zmieniają co kilka miesięcy o 180 stopni, kiedy tylko Dan Abramov znowu napisze coś na Twitterze, że coś, co radził kiedyś, już jest nieaktualne...)

A co za tym idzie - nie traktujcie tego jak prawdę objawioną (w zasadzie niczego nie powinno się tak traktować), po prostu jeden głos na temat Reduxa, jednocześnie entuzjastyczny, ale i krytyczny.