Zanim przejdziemy do oceny, wr\u00f3\u0107my do korzeni Reacta. Fundamentami ka\u017cdego komponentu s\u0105 w\u0142a\u015bciwo\u015bci (props<\/strong>) oraz stan (state<\/strong>). To w\u0142a\u015bnie stan odpowiada g\u0142\u00f3wnie za przechowywanie danych, kt\u00f3re nast\u0119pnie chcemy u\u017cy\u0107 w naszej aplikacji. To on powoduje ponowne wyrenderowanie komponentu w przypadku jakiejkolwiek zmiany.<\/p>\n\n\n\n React od wersji 16.8 pozwala nam korzysta\u0107 z tzw. hook\u00f3w<\/strong>. Dzi\u0119ki temu mo\u017cemy w pe\u0142ni zrezygnowa\u0107 z komponent\u00f3w klasowych, a skupi\u0107 si\u0119 na komponentach funkcyjnych. Dla przypomnienia, ka\u017cdy z hook\u00f3w musi zaczyna\u0107 si\u0119 od s\u0142owa \u2018use..\u2019<\/em> i mo\u017ce by\u0107 u\u017cyty jedynie w komponencie lub w innym hooku.<\/p>\n\n\n\n Jednym z najcz\u0119\u015bciej u\u017cywanych hook\u00f3w jest useState<\/em>, odpowiadaj\u0105cy za zarz\u0105dzanie stanem komponentu. Jego sk\u0142adnia wygl\u0105da nast\u0119puj\u0105co:<\/p>\n\n\n\n const [stan, funkcja_zmieniaj\u0105ca_stan] = useState(warto\u015b\u0107_pocz\u0105tkowa)<\/em>.<\/p>\n\n\n\n We\u017amy na przyk\u0142ad prosty dialog. Przy pierwszym wyrenderowaniu aplikacji nie chcemy, aby by\u0142 on wy\u015bwietlany. Nast\u0119pnie, po klikni\u0119ciu na przycisk, dialog powinien si\u0119 otworzy\u0107. Mo\u017cemy to zapisa\u0107 w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n\n\n\n Jak mo\u017cemy zauwa\u017cy\u0107, implementacja jest bardzo prosta i przejrzysta. Ka\u017cda zmiana stanu odpowiednio renderuje komponent i mogliby\u015bmy stwierdzi\u0107, \u017ce \u017cadne dodatkowe narz\u0119dzie nie jest nam potrzebne. Miejmy jednak na uwadze, \u017ce jest to bardzo trywialna aplikacja, wy\u015bwietlaj\u0105ca jedynie statyczne informacje. Co jednak w przypadku, je\u015bli nasz program pobiera\u0142by informacje z backendu, a nast\u0119pnie wy\u015bwietla\u0142 je w kilku r\u00f3\u017cnych miejscach?<\/p>\n\n\n\n Z pomoc\u0105 przychodzi nam kontekst<\/strong>, kt\u00f3rego aktualn\u0105 wersj\u0119 wprowadzono w React 16.3. Jest to mechanizm, kt\u00f3ry upraszcza przekazywanie danych pomi\u0119dzy komponentami, niweluj\u0105c przy tym zjawisko tzw. \u2018prop-drillingu<\/strong>\u2019. W React informacje przekazywane s\u0105 jednokierunkowo \u2013 od komponent\u00f3w rodzica do komponent\u00f3w dziecka. Przy bardziej rozbudowanych aplikacjach powstaj\u0105ce drzewo zale\u017cno\u015bci potrafi by\u0107 naprawd\u0119 obszerne. Cz\u0119sto okre\u015blon\u0105 informacj\u0119 powinni\u015bmy wy\u015bwietli\u0107 w najni\u017cszym szczeblu drzewa.<\/p>\n\n\n\n Zak\u0142adaj\u0105c, \u017ce dane pobieramy raz, w komponencie rodzica, jeste\u015bmy zmuszeni przekazywa\u0107 propsy<\/em> przez po\u015brednie komponenty, kt\u00f3re nawet z tych danych nie korzystaj\u0105. Pe\u0142ni\u0105 one jedynie rol\u0119 po\u015brednika. Zmniejsza to czytelno\u015b\u0107 kodu, a tak\u017ce powoduje niepotrzebne rendery w przypadku zmian.<\/p>\n\n\n\n Opisane zjawisko \u2018prop-drillingu<\/strong>\u2019 jest eliminowane dzi\u0119ki u\u017cyciu kontekstu. Mechanizm ten jest bardzo prosty w implementacji. Wymaga wykonania 3 krok\u00f3w:<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n W tak skonfigurowanej aplikacji jeste\u015bmy w stanie (gra s\u0142\u00f3w niezamierzona) w \u0142atwy spos\u00f3b skorzysta\u0107 ze wsp\u00f3\u0142dzielonych danych na dowolnym poziomie zagnie\u017cd\u017cenia komponentu. Do tego celu mo\u017cemy u\u017cy\u0107 kolejnego z hook\u00f3w, jaki daje nam do dyspozycji React \u2013 useContext<\/em>. Jedyne, co musimy przekaza\u0107, to nazwa kontekstu, z kt\u00f3rego chcemy skorzysta\u0107 (w aplikacji mo\u017cemy mie\u0107 ich wiele). Nast\u0119pnie mo\u017cemy odczyta\u0107 interesuj\u0105c\u0105 nas warto\u015b\u0107, kt\u00f3r\u0105 planujemy wy\u015bwietli\u0107:<\/p>\n\n\n\n Proste, prawda? Musimy jednak pami\u0119ta\u0107, \u017ce sam Context API nie jest mechanizmem do zarz\u0105dzania stanem<\/strong>! Jest to zestaw narz\u0119dzi, kt\u00f3re pomagaj\u0105 przekazywa\u0107 dane wzd\u0142u\u017c drzewa komponent\u00f3w. Jak mo\u017cna zauwa\u017cy\u0107 w poprzednich kawa\u0142kach kodu, do samego zarz\u0105dzania stanem u\u017cyty zosta\u0142 podstawowy hook Reacta \u2013 useState<\/em>. Warto o tym pami\u0119ta\u0107, poniewa\u017c cz\u0119sto kontekst jest mylnie nazywany narz\u0119dziem do zarz\u0105dzania stanem aplikacji. Tymczasem niczym on nie zarz\u0105dza, jedynie pozwala nam dosta\u0107 si\u0119 do wymaganych danych, bez konieczno\u015bci mozolnego przekazywania zale\u017cno\u015bci w d\u00f3\u0142 drzewa komponent\u00f3w.<\/p>\n\n\n\n Przy coraz bardziej rozbudowanych aplikacjach korzystaj\u0105cych z coraz wi\u0119kszej liczby danych, u\u017cycie kontekstu mo\u017ce by\u0107 problematyczne. Przede wszystkim nie jest on przystosowany do cz\u0119stych zmian. Przyczynia si\u0119 to do spadku wydajno\u015bci, a tak\u017ce szybko\u015bci dzia\u0142ania aplikacji. W przypadku wielu kontekst\u00f3w, jeste\u015bmy r\u00f3wnie\u017c zmuszeni do opakowania aplikacji ka\u017cdym z nich, co zmniejsza czytelno\u015b\u0107 kodu.<\/p>\n\n\n\n Naprzeciw tym problemom wychodzi Redux, pe\u0142noprawna biblioteka zarz\u0105dzania stanem, najcz\u0119\u015bciej stosowana w\u0142a\u015bnie z Reactem<\/strong>. Bazuje ona na architekturze Flux, o kt\u00f3rej wi\u0119cej mo\u017cecie przeczyta\u0107 w artykule na naszym blogu.<\/a><\/p>\n\n\n\n Opisuj\u0105c za\u0142o\u017cenia Reduxa, mo\u017cna wyodr\u0119bni\u0107 3 g\u0142\u00f3wne zasady:<\/p>\n\n\n\n To, \u017ce stan powinien by\u0107 niezmienialny, a jednak go aktualizujemy, mo\u017ce by\u0107 pocz\u0105tkowo myl\u0105ce. Warto pami\u0119ta\u0107, \u017ceby nigdy nie modyfikowa\u0107 istniej\u0105cego obiektu stanu<\/strong>, natomiast zawsze pracowa\u0107 na jego kopii.<\/p>\n\n\n\n Przejd\u017amy do stworzonego wcze\u015bniej dialogu i za\u0142\u00f3\u017cmy, \u017ce chcemy doda\u0107 kolejne pole z danymi u\u017cytkownika \u2013 tym razem jego wiek. Warto\u015b\u0107 ta mo\u017ce by\u0107 zmieniana przy pomocy przycisk\u00f3w + oraz -, a tak\u017ce po wpisaniu warto\u015bci do pola tekstowego. Zobaczmy wi\u0119c, jakie kroki musimy wykona\u0107, aby zaimplementowa\u0107 t\u0119 logik\u0119 przy pomocy Reduxa.<\/p>\n\n\n\n Dla cel\u00f3w edukacyjnych u\u017cy\u0142em podej\u015bcia, kt\u00f3re przez tw\u00f3rc\u00f3w uznawane jest za nieaktualne (deprecated<\/em>), ale lepiej pokazuje za\u0142o\u017cenia biblioteki. Pod koniec artyku\u0142u kr\u00f3tko opisz\u0119 nowoczesne standardy. Zacznijmy od tego, \u017ce jako zewn\u0119trzn\u0105 paczk\u0119, Reduxa najpierw musimy zainstalowa\u0107. W przypadku Reacta powinni\u015bmy zainstalowa\u0107 2 biblioteki \u2013 redux<\/strong>, a tak\u017ce react-redux<\/strong>. Kolejnym krokiem jest stworzenie naszego magazynu (store<\/strong>). Do tego celu b\u0119dzie nam potrzebny tak\u017ce reducer<\/strong>, kt\u00f3ry nale\u017cy przekaza\u0107 przy kreacji magazynu.<\/p>\n\n\n\n Reducer <\/strong>przyjmuje 2 argumenty \u2013 aktualny stan oraz akcj\u0119. Je\u015bli s\u0142owo reducer <\/strong>brzmi znajomo, to dlatego, \u017ce pochodzi ono od metody Array.reduce().<\/em> W ten sam spos\u00f3b przyjmuje za argumenty aktualny stan, a tak\u017ce kolejn\u0105 warto\u015b\u0107, kt\u00f3r\u0105 nale\u017cy obs\u0142u\u017cy\u0107. Mo\u017cna powiedzie\u0107, \u017ce reducer <\/strong>\u201ezbiera\u201d wszystkie akcje, aby na sam koniec sprowadzi\u0107 je jednej ko\u0144cowej warto\u015bci w postaci stanu. Ka\u017cda akcja <\/strong>musi mie\u0107 okre\u015blony typ, na podstawie kt\u00f3rego reducer <\/strong>decyduje, w jaki spos\u00f3b stan powinien by\u0107 zaktualizowany. Akcja mo\u017ce mie\u0107 tak\u017ce jaki\u015b \u0142adunek informacji (payload<\/strong>).<\/p>\n\n\n\n Jak mo\u017cemy zauwa\u017cy\u0107, w przypadku aktualizacji stanu, zwracana jest jego kopia, nigdy nie modyfikujemy bezpo\u015brednio istniej\u0105cego stanu! Gdy przekazana do reducera akcja nie jest znana, a tym samym \u017cadna warto\u015b\u0107 nie jest aktualizowana, zwr\u00f3cony powinien zosta\u0107 aktualny stan.<\/p>\n\n\n\n Stworzyli\u015bmy magazyn oraz funkcj\u0119 obs\u0142uguj\u0105c\u0105 przychodz\u0105ce zmiany. Teraz pora u\u017cy\u0107 przygotowanych danych w komponentach. W tym celu powinni\u015bmy opakowa\u0107 nasz\u0105 aplikacj\u0119 przy u\u017cyciu komponentu Providera<\/strong> (podobnie jak w przypadku kontekstu), tym razem importowanegoz biblioteki react-redux.<\/em> Do komponentu nale\u017cy przekaza\u0107 stworzony store<\/strong>.<\/p>\n\n\n\n Dzi\u0119ki temu umo\u017cliwili\u015bmy komponentom naszej aplikacji dost\u0119p do magazynu z globalnymi danymi. Spr\u00f3bujmy je w takim razie wykorzysta\u0107. Do tego celu s\u0142u\u017cy hook useSelector<\/em>, kt\u00f3rego argumentem jest funkcja okre\u015blaj\u0105ca jak\u0105 cz\u0119\u015b\u0107 stanu chcemy wykorzysta\u0107. Nast\u0119pnie mo\u017cemy u\u017cywa\u0107 danej warto\u015bci jak zwyk\u0142ej zmiennej.<\/p>\n\n\n\n Przejd\u017amy teraz do bardziej interesuj\u0105cej kwestii \u2013 wys\u0142ania akcji w celu aktualizacji stanu. Tutaj powinni\u015bmy skorzysta\u0107 z kolejnego hooka biblioteki react-redux<\/em> \u2013 useDispatch<\/em>. Wywo\u0142anie tego hooka daje nam dost\u0119p do funkcji, dzi\u0119ki kt\u00f3rej mo\u017cemy wysy\u0142a\u0107 akcje <\/strong>do reducera<\/strong>. Naciskaj\u0105c na przycisk \u2018+\u2019,<\/em> chcieliby\u015bmy zwi\u0119kszy\u0107 wiek u\u017cytkownika. W przypadku klikni\u0119cia w przycisk \u2018-\u2019 <\/em>wykona\u0107 adekwatn\u0105 operacj\u0119.<\/p>\n\n\n\n Aby umo\u017cliwi\u0107 te zdarzenia, nale\u017cy przypisa\u0107 odpowiednie handlery dla event\u00f3w \u2018onClick\u2019<\/em>. W handlerach u\u017cywamy funkcji dispatch<\/strong>, do kt\u00f3rej przekazujemy odpowiednie obiekty akcji<\/strong>. Ka\u017cdy z tych obiekt\u00f3w musi zawiera\u0107 typ, na podstawie kt\u00f3rego reducer<\/strong> zaktualizuje stan. Typ wys\u0142anej akcji jest taki sam, jak uprzednio u\u017cyty w stworzonym reducerze. Na tej podstawie mo\u017ce on odpowiednio zareagowa\u0107. Obiekt akcji mo\u017ce tak\u017ce zawiera\u0107 jak\u0105\u015b informacj\u0119 w postaci payloadu. W naszym przypadku jest to wpisany przez u\u017cytkownika wiek, kt\u00f3ry przekazywany jest do nowego stanu aplikacji (nawiasem m\u00f3wi\u0105c, warto takie update\u2019y opakowa\u0107 w funkcj\u0119 debounce<\/strong>, aby unikn\u0105\u0107 niepotrzebnych aktualizacji stanu przy ka\u017cdej interakcji u\u017cytkownika).<\/p>\n\n\n\n Podsumowuj\u0105c, stworzyli\u015bmy magazyn (store<\/strong>), kt\u00f3ry jest naszym jedynym \u017ar\u00f3d\u0142em prawdy. Do magazynu przekazali\u015bmy reducera<\/strong>, kt\u00f3ry okre\u015bla, jak stan powinien by\u0107 aktualizowany w czasie (nie bezpo\u015brednio zmieniany!), na podstawie przychodz\u0105cych akcji<\/strong>. Akcje<\/strong> opisuj\u0105, co w naszej aplikacji si\u0119 wydarzy\u0142o. Wydarzenia te wysy\u0142ane s\u0105 zazwyczaj na podstawie interakcji u\u017cytkownika z naszym UI (wci\u015bni\u0119cie przycisku, zmiana warto\u015bci pola) przy u\u017cyciu dispatchera<\/strong>. Aby wykorzysta\u0107 istniej\u0105ce dane przechowywane w magazynie, wystarczy zasubskrybowa\u0107 si\u0119 do zmian przy u\u017cyciu selektora<\/strong>. Ka\u017cda zasubskrybowana zmiana wp\u0142ywa na ponowne renderowanie UI. Proste, prawda?<\/p>\n\n\n\n Ciekawostk\u0105 jest, \u017ce react-redux<\/em> do przekazywania danych pomi\u0119dzy komponentami u\u017cywa kontekstu. Przekazuje instancj\u0119 magazynu<\/strong>, a nie aktualn\u0105 warto\u015b\u0107 stanu, co korzystnie wp\u0142ywa na performance.<\/p>\n\n\n\n Niezmienialno\u015b\u0107 stanu aplikacji (tworzenie nowego stanu przy ka\u017cdej akcji) ma tak\u017ce wa\u017cn\u0105 implikacj\u0119 \u2013 dzi\u0119ki niej mo\u017cemy skorzysta\u0107 z takich narz\u0119dzi jak Redux DevTools<\/em>, kt\u00f3re pozwalaj\u0105 nam odtworzy\u0107 histori\u0119 poszczeg\u00f3lnych zmian w czasie. Bardzo przydatna rzecz przy debugowaniu.<\/p>\n\n\n\n Na koniec obiecane nowoczesne (aktualnie polecane przez tw\u00f3rc\u00f3w) podej\u015bcie do tematu implementacji Reduxa. U\u0142atwia prac\u0119, poniewa\u017c nie zmusza implementuj\u0105cego do ka\u017cdorazowego tworzenia kopii istniej\u0105cego stanu, a tak\u017ce zapobiega powtarzaj\u0105cym si\u0119 b\u0142\u0119dom. Poprzednie przyk\u0142ady s\u0142u\u017cy\u0142y g\u0142\u00f3wnie pokazaniu jak Redux dzia\u0142a, natomiast to jak powinni\u015bcie go implementowa\u0107 w istniej\u0105cych aplikacjach, opisuje poni\u017csze podej\u015bcie.<\/p>\n\n\n\n Opiera si\u0119 ono na bibliotece @reduxjs\/toolkit<\/em> (nazywanej te\u017c skr\u00f3towo RTK). W tym wypadku tworzymy store<\/strong> przy u\u017cyciu funkcji configureStore<\/em>, do kt\u00f3rej przekazujemy naszego reducera<\/strong>. Zalet\u0105 tego jest automatyczna konfiguracja podstawowych narz\u0119dzi do pracy z Reduxem, m.in ustalenie po\u0142\u0105czenia do wspomnianego wcze\u015bniej Redux DevTools<\/em>, a tak\u017ce wbudowane oprogramowania po\u015brednie (middleware<\/em>), takie jak redux-thunk<\/em>.<\/p>\n\n\n\n Tworzenie samego reducera<\/strong> tak\u017ce zosta\u0142o uproszczone. Logika oparta jest na podzieleniu wi\u0119kszego stanu na kawa\u0142ki (slice<\/strong>). Wykorzystana zostaje funkcja createSlice()<\/em>, do kt\u00f3rej przekazane zostaj\u0105 nazwa, stan pocz\u0105tkowy oraz obiekt reducers<\/em>, kt\u00f3ry zawiera funkcje, obs\u0142uguj\u0105ce poszczeg\u00f3lne akcje. Jest to analogia do konstrukcji switch\/case<\/em>, kt\u00f3r\u0105 zaimplementowali\u015bmy wcze\u015bniej. Domy\u015blna warto\u015b\u0107 \u2018starego\u2019 switcha jest ju\u017c za nas automatycznie przekazywana.<\/p>\n\n\n\n Co ciekawe createSlice()<\/em> pozwala nam mutowa\u0107 stan! Jest to jedynie pozorne mutowanie<\/strong>, gdy\u017c pod spodem dzia\u0142a biblioteka Immer<\/strong>, kt\u00f3ra odnotowuje wszelkie zmiany, a nast\u0119pnie zwraca za nas nowy, zaktualizowany, lecz tak\u017ce niezmienialny stan. Wykonuje za nas prac\u0119, dzi\u0119ki czemu nie musimy skupia\u0107 si\u0119 na kopiowaniu ka\u017cdej w\u0142a\u015bciwo\u015bci obiektu, szczeg\u00f3lnie tej g\u0142\u0119boko zagnie\u017cd\u017conej. Kolejnym plusem<\/strong> jest to, \u017ce akcje s\u0105 automatycznie tworzone, na podstawie funkcji przekazanych do obiektu reducers<\/em>. Ze stworzonego \u2018slice\u2019a\u2019<\/em> mo\u017cemy wyeksportowa\u0107 wygenerowany reducer<\/em>, kt\u00f3ry zostanie u\u017cyty przy tworzeniu magazynu (store).<\/p>\n\n\n\n Wykorzystanie danych przechowywanych w magazynie, a tak\u017ce wysy\u0142anie aktualizacji stanu pozostaje takie samo jak w klasycznym podej\u015bciu \u2013 przy u\u017cyciu hook\u00f3w useSelector<\/em> oraz useDispatch<\/em>. W przypadku tego pierwszego, musimy pami\u0119ta\u0107, aby najpierw sprecyzowa\u0107 reducer, do kt\u00f3rego si\u0119 odwo\u0142ujemy. Jego nazwa musi by\u0107 identyczna, jak ta przekazana do obiektu reducers przy konfiguracji store\u2019a.<\/p>\n\n\n\n Wykorzystanie useDispatch<\/em> zosta\u0142o uproszczone \u2013 pozostaje nam jedynie przekaza\u0107 automatycznie wygenerowan\u0105 akcj\u0119, kt\u00f3r\u0105 importujemy z kawa\u0142ka (slice<\/strong>) naszego stanu. Akcja ta ma posta\u0107 funkcji, kt\u00f3rej wywo\u0142anie zostaje przekazane do dispatcha. Chc\u0105c przekaza\u0107 \u0142adunek (payload), odpowiedni\u0105 warto\u015b\u0107 przekazujemy do wywo\u0142ania akcji. Dzi\u0119ki temu nie jeste\u015bmy zmuszeni do \u017cmudnego tworzenia obiekt\u00f3w z typem, a czasem payloadem danego zdarzenia w aplikacji.<\/p>\n\n\n\n U\u017cycie biblioteki @reduxjs\/toolkit<\/em> w du\u017cym stopniu upraszcza prac\u0119 z Reduxem, a tak\u017ce niweluje powszechnie pope\u0142niane b\u0142\u0119dy. Mimo wszystko uwa\u017cam, \u017ce warto zna\u0107 podstawy dzia\u0142ania biblioteki<\/strong>, co tym bardziej pozwala doceni\u0107 zalety nowoczesnych rozwi\u0105za\u0144.<\/p>\n\n\n\n React zapewnia nam wiele mo\u017cliwo\u015bci, je\u015bli chodzi o zarz\u0105dzanie stanem. Tylko od nas zale\u017cy w jaki spos\u00f3b je wykorzystamy. Przede wszystkim sprecyzujmy nasze wymagania, a nast\u0119pnie dopasujmy do tego narz\u0119dzia, nie odwrotnie!<\/p>\n\n\n\n Czy powinni\u015bmy korzysta\u0107 z Reduxa? Oczywi\u015bcie. Czy powinni\u015bmy do\u0142\u0105cza\u0107 go do zale\u017cno\u015bci przy ka\u017cdej tworzonej aplikacji? Niekoniecznie.<\/p>\n\n\n\n Jak pokaza\u0142em w artykule, przy u\u017cyciu wbudowanych funkcjonalno\u015bci Reacta jeste\u015bmy w stanie poradzi\u0107 sobie ze \u015brednio skomplikowanymi problemami, gdzie dane s\u0105 wymagane w rozproszonych miejscach aplikacji. Nale\u017cy jednak pami\u0119ta\u0107, \u017ce w przypadku coraz bardziej rozbudowanych serwis\u00f3w, mo\u017cemy straci\u0107 kontrol\u0119 nad tym, jak nasz stan zmienia si\u0119 w czasie. Gdy widzimy, \u017ce nasz g\u0142\u00f3wny komponent zaczyna by\u0107 opakowywany w coraz wi\u0119cej kontekst\u00f3w, a ka\u017cdy z nich zawiera poka\u017an\u0105 liczb\u0119 funkcji aktualizuj\u0105cych stan, wtedy najwy\u017csza pora zwr\u00f3ci\u0107 si\u0119 do naszego starego przyjaciela, Reduxa<\/strong>.<\/p>\n\n\n\n ***<\/p>\n\n\n\n Je\u015bli interesuje Ci\u0119 tematyka Reacta i Fluxa, zajrzyj r\u00f3wnie\u017c do innych artyku\u0142\u00f3w naszych ekspert\u00f3w<\/a>. <\/p>\n\n\n![\"kod\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/04\/1.-Prosty-dialog-zarzadzany-stanem.png\")
<\/a><\/figure><\/div>\n\n\n\nContext API<\/strong><\/h2>\n\n\n\n
<\/a><\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\nRedux<\/strong><\/h2>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\nWysy\u0142anie akcji<\/strong><\/h2>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\nAktualnie zalecane podej\u015bcie do implementacji Reduxa<\/strong><\/h2>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\nCzy Redux to konieczno\u015b\u0107?<\/strong><\/h2>\n\n\n\n