React

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Patrykiem Omiotkiem o React.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość to programista z ponad 12-letnim doświadczeniem, specjalista od takich technologii jak Python, JavaScript, PHP i NoSQL, współzałożyciel Lublin IT, założyciel i nauczyciel w Szkole Reacta, wykładowca w Wyższej Szkole Przedsiębiorczości i Administracji w Lublinie, prelegent na konferencjach branżowych.

Moim i Waszym gościem jest dzisiaj Patryk Omiotek. Cześć, Patryk! Bardzo mi miło gościć Cię w podcaście!

Cześć, dzień dobry, bardzo mi miło!

Na początek standardowe pytanie wprowadzające — czy słuchasz podcastów, a jeśli tak to może masz jakieś swoje ulubione?

Tak, na to pytanie odpowiem może dość zaskakująco, ale raczej nie słucham podcastów. Z tego względu, że ta forma akurat do końca mi nie leży. Na takiej zasadzie, że robiłem kilka podejść do podcastów i tam jest bardzo dużo informacji, dużo mięcha, dużo wartościowych informacji i coś takiego mi do końca nie wchodzi przez sam dźwięk. Muszę widzieć obraz. Dla mnie już videocast albo film instruktażowy na YouTube pozwala tę wiedzę łatwiej przyswoić. Natomiast jeśli chodzi o formę audio — próbowałem wielokrotnie i bardziej do mnie trafiają audiobooki. Wiaodmo — to są książki, czasami się rozwlekają, jest jakaś ładna historia, więc tutaj nie trzeba mieć takiego skupienia. Natomiast przy podcastach, gdybym chciał tę całą wiedzę potem w jakiś sposób zapamiętać i wykorzystać to jednak dla mnie to nie jest idealna forma.

Rozumiem. Obserwuję cię w social mediach, widzę, że dużo działasz w obszarze Reacta, zresztą jesteś założycielem Szkoły Reacta, dlatego chcę cię dzisiaj trochę podpytać na temat tej części technologii, o której sporo się słyszy — bardzo szybko i dynamicznie się rozwija, więc może właśnie dzisiaj sobie o tym porozmawiamy.

Na początek taki trochę rys historyczny. Jakiś czas temu jeszcze wydawało się, że nic z tej hegemonii Angulara nie jest w stanie przełamać, a wówczas na scenę wkroczył React i pewnie o tym nie wiedział, bo to zrobił. Chcę Cię zapytać, jakie były okoliczności powstania Reacta? Kto w ogóle stoi za tą technologią? I dlaczego ten sukces Reacta nastąpił? Na jakie problemy był lekarstwem, skoro tak dobrze przyjął się w środowisku, skoro tak dynamicznie się rozwija?

Tutaj faktycznie możemy się trochę przenieść wstecz i mogę nieco powiedzieć o moich doświadczeniach. Byłem osobą, która po tej stronie frontendowej pojawiła się jakieś 6 lat temu — wcześniej głównie pracowałem po stronie backendu i trochę przyglądałem się tym technologiom frontendowym. Natomiast tam co chwilę wychodziła jakaś biblioteka, która za moment była już albo przestarzała, albo bardzo niestabilna.

Co nieco rozwiązań pojawiało się opartych o Angulara, więc akurat. Pierwszą taką poważną aplikację frontendową, jaką pisałem to był duży serwis dla znanej Akademii Filmowej, oparty właśnie o Angularze. I wtedy z perspektywy osoby przechodzącej z backendu Angular wyglądał w miarę korzystnie. To był jeszcze AngularJS, więc miał kontrolery, dyrektywy. Natomiast ten sam podział związany z budową aplikacji poprzez reużywanie komponentów bardzo przypadł do gustu i w końcu można było jakoś sensownie i w taki zaplanowany, przemyślany sposób te aplikacje frontendowe robić.

Natomiast po tym projekcie akurat mieliśmy taką sytuację, że w parę osób mieliśmy przerwę w projekcie, dokładnie chyba trzy tygodnie, więc ani długo, ani krótko. Mieliśmy okazję zapoznać się z Reactem i szczerze mówiąc za pierwszym razem nie przypadł nam kompletnie do gustu, z tego względu, że wcześniej backend, gdzie często chociażby wzorzec MVC był wykorzystywany w Angularze też taki podział widoku i logiki jest zastosowany i nagle przychodzi React, w którym jest JSX, czyli z powrotem mamy mieszankę widoku, wstawianie tam zmiennych. Wygląda to, jak XML i pierwsze wrażenie było tragiczne.

Natomiast po tym projekcie akurat mieliśmy taką sytuację, że w parę osób mieliśmy przerwę w projekcie, dokładnie trzy tygodnie, więc ani długo, ani krótko. Mieliśmy okazję zapoznać się z Reactem i szczerze mówiąc za pierwszym razem nie przypadł nam kompletnie do gustu.

A z drugiej strony stwierdziliśmy, że jest to biblioteka, która była zrobiona przez twórców Facebooka, więc przez takich łebskich developerów, którzy mają dużo więcej doświadczenia w tym temacie niż my, to damy im szansę. I faktycznie po trzech tygodniach w miarę to zaczęło nabierać sensu, że oni oparli to wszystko na JSX i oparli na komponentach, dzięki temu te komponenty w fajny sposób można budować, testować i reużywać.

Tutaj taka ciekawostka — JSX i ogólnie React był bodajże w 2015 roku oficjalnie zaprezentowany, natomiast ta cała składnia pozwalająca na mieszanie JavaScriptu i HTML-u była inspirowana przez rozwiązanie XHP, które było napisane w PHP-ie. Czyli właśnie łączyć XML-a z PHP-em, aby wytworzyć też takie komponenty po stronie PHP-owej. To bodajże w 2010 roku powstało, a chyba w 2015 już wyszła taka finalna wersja w Reactcie. Także trochę developerzy Facebooka zaczerpnęli od developerów swoich kolegów z Facebooka, którzy właśnie po stronie backendu to pisali.

Akurat w tym okresie, gdy był AngularJS i React zdobywał popularność, to dużo łatwiej można było pisać apki, szybciej i też przyjemniej. Dlatego Rect też wstrzelił się w dobry czas.

W sumie pewnie nic nowego, że w IT, w programowaniu się inspirują znajomą pracą, też te koncepty, które wymyślone były nawet kilkadziesiąt lat temu wracają. I tak też zresztą dzieje się teraz, mamy okazję co chwilę obserwować jakieś nowe mody, które wydają się właśnie czymś nowym, a to czasem są te koncepty powracające.

Takim też konceptem jest trochę programowanie reaktywne, na którym jest właśnie React oparty. I o ile powiedzmy mówi się, że w programowaniu nazywanie rzeczy jest jedną z najtrudniejszych spraw, o tyle w przypadku Reacta może nie była to aż taka trudność. No bo React, programowanie reaktywne może się tutaj jedno z drugim dosyć dobrze wiązać. Zresztą tak jest, prawda? Bo ten paradygmat reaktywny jest czymś, na czym React stoi.

Chcę Cię poprosić, żebyś właśnie trochę opowiedział o tym paradygmacie programowania, o tym, na jakich podstawach się to w ogóle opiera?

Tutaj musimy sobie przypomnieć jak możemy sobie podzielić różne paradygmaty, jakie są paradygmaty programowania. Możemy zrobić taki podział dość znany od wielu lat na programowanie imperatywne i deklaratywne. Czyli w programowaniu imperatywnym my przekazujemy informacje — piszemy kod w taki sposób, gdzie wydajemy w jawny sposób instrukcje, natomiast w programowaniu deklaratywnym bardziej skupiamy się na celu, jaki chcemy osiągnąć i nie do końca musimy ten cel definiować. Tutaj skupimy się głównie na tym, jak osiągnąć dany rezultat.

Widziałem dużo, różnych definicji programowania reaktywnego czy programowania deklaratywnego. I jedną z takich ciekawszych, jakie widziałem, to programowanie reaktywne jest programowaniem wykorzystującym asynchroniczne strumienie danych. Jakkolwiek by to nie zabrzmiało, to jest coś, co nie tylko po stronie backednowej, ale bardzo po stronie tej frontendowej, gdzie mamy interfejs przeglądarki fajnie się sprawdza.

Bo chociażby taki asynchroniczny strumień danych — to może być czy kliknięcie użytkownika w przycisk czy rozpoczęcie wpisywania w jakieś pole tekstowe czy pokazywanie, ukrywanie jakiegoś elementu na ekranie i tutaj przy budowie interfejsu no to już te rzeczy, które wymieniłem — efekty, które chcemy osiągnąć, natomiast bardzo często nie musimy pisać od A do Z wszystkich instrukcji, co chcielibyśmy zrobić, żeby na ekranie się namalowało i przerysowało, tylko korzystamy, chociażby ze zdarzeń, a React bardzo nam ułatwia wykorzystywanie tych zdarzeń.

W programowaniu reaktywnym również chodzi nam o to, aby tworzyć w taki sposób asynchroniczny, w taki sposób, aby nie blokować przetwarzania danych. W aplikacjach frontendowych, które są z natury asynchroniczne, tworzenie kilku operacji naraz jest jak najbardziej wskazane i po prostu przyjemne.

Oczywiście to wszystko możemy uzyskać za pomocą czystego JavaScripta, natomiast są szybsze drogi — biblioteki i frameworki, pozwalające nam sprawniej, szybciej te interfejsy budować.

Jakby tak popatrzeć na ilość linii kodu albo powiedzmy wielkość w kilobajtach czy megabajtach, to React można powiedzieć, że jest lekki — w porównaniu, chociażby do innych bibliotek czy frameworków.

To jest takie kluczowe rozróżnienie — bo o Reactcie mówi się jako o bibliotece, a nie o frameworku — jestem ciekawy, co Ty o tym myślisz. I poproszę też, żebyś powiedział na jakich podstawach, na jakich założeniach opiera swoje działania właśnie React?

W porządku. Sam akurat chyba dlatego dość długo korzystam z Reacta, ponieważ lubię takie rozwiązania polegające na tym, że masz bibliotekę i możesz z tego zrobić co chcesz. Nie masz narzuconych zasad właściwie jak masz to robić, coś tam mi przeszkadzało jeszcze w pracy backendowej, bo wówczas za bardzo nie przepadałem za frameworkami, korzystałem z takich większych bibliotek. Akurat w moim przypadku to był Zend Framework, w którym był w nazwie „framework”, ale właściwie był biblioteką. Tak inżynierowie z A&S-u — ciekawe podejścia. W niektórych kwestiach. Natomiast gdy widziałem Angulara i Reacta, no to faktycznie mi się bardziej React spodobał ze względu na to, że on jest lekki, daje mi właściwie kilka metod dostępu do swojego interfejsu api, za pomocą których szybko mogę stworzyć te komponenty, a z komponentów aplikacje.

To, co mnie też przekonało do Reacta to mechanizm virtual DOM-u, czyli React, zanim cokolwiek przekaże do naszej przeglądarki, to najpierw ma swoje algorytmy i te algorytmy updateują wirtualne drzewo DOM. Dopiero gdy zupdate’ują, jest potrzeba zmiany tego wirtualnego drzewa-dom, to wówczas operacje są przenoszone do naszej przeglądarki i faktycznie wtedy przeglądarka przerenderuje nam jakiś element na ekranie.

To jest na tyle istotne, bo same operacje na drzewie DOM są dość czasochłonne, jeżeli nałoży się kilka różnych efektów czy kilka różnych animacji — nasza aplikacja po prostu spowalnia swoje działania. Natomiast myślę, że ten virtual DOM to też był taki killing feature, jeżeli chodzi o ten okres, gdy React wchodził i jeszcze AngularJS był na rynku, wówczas on tego nie miał. On operował głównie na drzewie DOM. Ze względu na szybkość działania i mniejszą wagę. Porównując: mam małą biblioteczkę, za pomocą której możemy zrobić dużo w porównaniu do innych rozwiązań, to jest coś, co przeważyło przy wyborze.

Jasne, rozumiem. We wprowadzeniu mówiłem, że jesteś twórcą Szkoły Reacta i w tej szkole właśnie uczysz zarówno początkujących,, jak i zaawansowanych, widziałem, że tych modułów już trochę jest. Mówisz też, widzę często na social mediach, że to jest taka szansa na znalezienie lepszej pracy.

Dlatego chcę Cię zapytać — jak wygląda obecnie popularność Reacta w projektach? Czy są może jakieś ankiety, czy może jakieś oszacowanie rynku, które mówi jak popularny jest React i z drugiej strony — jak obecnie wygląda rynek pracy?

Odniosę się głównie do polskiego rynku pracy, ponieważ w zagranicznym moim zdaniem jest React przeważający, natomiast nie mam pełnych danych czy wyników raportu, do których mógłbym odesłać. Natomiast jeśli chodzi o polski rynek, to mogę powiedzieć też cofając się kilka lat wstecz — jeżeli aplikowało się pięć lat temu na pozycję frontend developera, to wystarczał już dobra znajomość JavaScript, HTML, CSS. Natomiast od półtora roku, dwóch lat, osoby aplikujące nawet na stanowisko juniora — wymagana jest znajomość przynajmniej Reacta, Angulara albo Vue. To wynika też z tego względu, że świadomość klientów bardzo poszła do przodu. Zdają sobie oni sprawę z rozwiązań technicznych, za pomocą których mogą albo po prostu chcą oprzeć swoje aplikacje, więc my bardzo często jak dostajemy wstępny projekt od klienta do wyceny, to on już mówi — chcę to zrobić w Reakcie, bo być może potem będę chciał aplikację mobilną, to niech zrobi mi ten sam zespół w React native.

Natomiast ja jako osoba, która z jednej strony pracuje też z klientami, widzi jakie oni mają wymagania i gdzie oni sami już do nas przychodzą i to przeważnie jest React, natomiast z drugiej strony też widzę to, że nie tylko firma, w której ja pracuję na co dzień, ale większość takich firm nie chce sobie pozwolić za bardzo na to, żeby przyjąć osobę bez znajomości czy Reacta, Angulara czy Vue, ponieważ później firma musi zainwestować czas w naukę. Skoro większość projektów i tak robimy za pomocą któregoś z tych trzech rozwiązań, to oczywiście wygodniej i taniej dla firmy jest, aby taki pracownik już miał przynajmniej średnie doświadczone. Jeżeli chodzi o juniorów to też widzę, że poprzeczka się podniosła dość wysoko, bo kiedyś wystarczyła podstawowa znajomość, a teraz fajnie, gdyby junior znał Reacta i miał dwa lata doświadczenia komercyjnego.

Także trochę ten rynek się z czasem zmienia — natomiast to już jest moim zdaniem taki must have, żeby nawet starać się o pozycję juniora.

Dobrze, to wrócimy trochę od kodu. Jak powiedziałeś — Reacta dodaje się do projektu jako taką bibliotekę. Wiadomo, że to jest pewna swoboda, pewna wolność, ale z wolnością zawsze idzie jakaś odpowiedzialność. W związku z tym, jak według ciebie mogłaby wyglądać taka przykładowa architektura aplikacji tworzonej za pomocą Reacta? Jakbyś to złożył?

Ogólnie architektura aplikacji reactowych i sterowanie to są dwa tematy, gdzie największe są wojny religijno-techniczne, w świecie reactowym. Ale jeżeli chodzi o architekturę, to w ciągu ostatnich lat zostało to w miarę doprecyzowane. Są już jakieś dobre praktyki, dobre wzorce. W tym momencie, jeżeli tworzymy aplikację reactową, to możemy podzielić strukturę na kilka sposobów.

Ogólnie architektura aplikacji reactowych i sterowanie to są dwa tematy, gdzie największe są wojny religijno-techniczne, w świecie reactowym. Ale jeżeli chodzi o architekturę, to w ciągu ostatnich lat zostało to w miarę doprecyzowane. Są już jakieś dobre praktyki, dobre wzorce. W tym momencie, jeżeli tworzymy aplikację reactową, to możemy podzielić strukturę na kilka sposobów.

Możemy podejść do tego domenowo, czyli stworzyć sobie jakieś domeny, niech to będą użytkownicy, zamówienia, płatności. W środku tych folderów przehocywwać komponenty, które będą nam pobierały jakieś dane i je wysyłały, i w środku tych folderów możemy stworzyć sobie komponenty prezentacyjne, które tylko będą nam to wyświetlały.

Czasami to podejście jest jak najbardziej okej, ale w wielu miejscach zaczyna być niewystarczające, jeżeli nasze komponenty między tymi właściwie domenami miałyby być używane. Jeżeli więc nam tutaj dochodzi przycisk albo tabela, która ma być wykorzystywana tutaj i tutaj, no to pojawia się pewien problem.

Ogólnie jeden z głównych kontrybutorów Reacta, Dan Abramov stworzył nawet taką stronę i tam jest hasło — „Jak tworzyć architekturę w Reakcie?”. I on powiedział: „Przenoś pliki i katalogi tak długo, aż poczujesz, że to spełnia się w twoim projekcie”. Podejście też jest inne, my możemy sobie podzielić aplikacje, chociażby na — to bardziej z Next.js-a jest zaczerpnięte — na folder, który trzyma strony. Czyli te komponenty, które są bezpośrednio z routingiem spięte i one będą nam reagowały na routing i pobierały dane.

Natomiast pozostałe komponenty możemy podzielić na komponenty właśnie prezentacyjne, gdzie z góry te dane otrzymamy i zostaną tylko wyświetlone. Albo też po prostu trzymać folder „components” i w środku komponenty, ale to przy mniejszych projektach się sprawdzi, bo gdzieś musimy jeszcze dorzucić znowu tę warstwę biznesową bardziej i gdzieś w takim razie komponenty, które są kontenerami powinniśmy dodać, więc to trochę zależy od projektu.

Jednej sprawdzonej architektury na pewno nie ma, natomiast te kilka wymienionych najczęściej się sprawdzają. Korzystając z tych, myślę, że większość aplikacji frontendowych możemy sobie przygotować.

Jakiś czas temu takim dużym wydarzeniem w świecie Reacta było pojawienie się hooków. Dużo się o tym pisało, mówiło — chciałbym cię poprosić, abyś w skrócie powiedział, czym React Hooki są i czy w twojej ocenie — bo już trochę czasu minęło od momentu, kiedy się pojawiły, czy nadal można je nazywać takim rewolucyjnym feature’em w Reakcie?

Hooki się pojawiły równo dwa lata temu. Czy są rewolucyjnym feature’em? Wydaje mi się, że tak. Bo w wielu projektach jeszcze się korzysta z tego podejścia klasowego, natomiast tutaj chciałbym wyraźnie zaznaczyć — bo są duże kłótnie w internecie, czy korzystać z klas, czy korzystać z hooków. Sami twórcy Reakta mówią, żeby pisać jak nam jest wygodniej.

Hooki natomiast dały nam możliwość tworzenia komponentów, tworzenia kodu wyłącznie w sposób funkcyjny, bo zanim zostały wprowadzone Hooki, gdy potrzebowaliśmy korzystać ze stanu wewnętrznego naszej aplikacji czy life cycle methods na zasadzie pobierać dane w komponencie i potem te dane przekazać dalej, to musieliśmy po prostu tworzyć klasy.

Natomiast klasy w JavaScripcie są takim trochę sztucznym tworem, JavaScript jest z natury bardziej językiem funkcyjnym, którym i tak wszystko jest obiektem, natomiast w samym Reakcie dzięki temu, że Hooki zostały wprowadzone, to jedną z takich prostszych rzeczy jest oczywiście to, że nie musimy już korzystać z komponentów klasowych, natomiast to daje trochę innych, ważnych zalet, które są niedostrzegane, mianowicie sposób organizacji naszych projektów i samych komponentów musimy teraz nieco dokładniej przemyśleć, żeby nie narobić bałaganu. W przypadku komponentów klasowych łatwo można było narobić takich smaczków jak ze świata bardziej backendowego, że nasze klasy mają po kilkaset linijek i tam siedzi wszystko. Natomiast Hooki już naprawdę dają możliwość — trzeba mocno przemyśleć te komponenty, ale też dużo sprawniej, dużo łatwiej można je przetestować, ponieważ klasy sprawiały pewne problemy jeżeli chodzi o testowanie komponentów.

Odpowiadając na twoje pytanie, czy są czymś rewolucyjnym — wciąż tak, ponieważ dużo projektów, które zostały rozpoczęte jakiś czas temu, przynajmniej dwa albo rok temu, wykorzystują te klasy i do nich tak już developerzy albo przerzucają powoli te Hooki, albo starają się nowe obszary projektu pisać hookowo. Bo jest to wygodniejsze, szybsze, też te aplikacje też są trochę bardziej optymalne. Często na rekrutacjach technicznych zadaję kandydatom pytania — klasy czy Hooki, co wolą, także też widzę, że jednak ludziom coraz bardziej te hooki odpowiadają niż podejście klasowe.

Okej, rozumiem. Wspomniałeś chwilę o testowaniu i ten wątek chciałbym przez moment pociągnąć. Mam wrażenie, że jako branża programistyczna już lepiej rozumiemy, że testy są potrzebne i są nieodłączną częścią tego, co na co dzień robimy.

Jak wygląda temat testowania w momencie, kiedy mamy w projekcie Reakta? To coś zmienia, coś daje? Jakie praktyki się stosuje?

Sam React jako tako nie daje nam za bardzo dodatkowej wygody czy możliwości, jeżeli chodzi o testowanie, w porównaniu do innych rozwiązań javascriptowych, natomiast bardziej się zmieniły czasy, jeżeli chodzi o frontend. Kiedyś testowanie aplikacji javascriptowych, zwłaszcza jeżeli chodzi — zacznę od testów end to end, to była jakaś masakra.

Testy uruchamiały się bardzo długo, bardzo często sama konfiguracja zajmowała masę czasu. Było czasami tam Selenium, który nie wszystkim frontend developerom podpasuje i wydaje mi się, że kiedy pojawił się Cypress, no to jednak życie stało się trochę prostsze, przynajmniej pod tym kątem testowania end to end, gdzie my możemy sobie te testy wyklikać, ale w sumie też często się je po prostu pisze bardzo wygodnie za pomocą ładnej i przyjemnej składni, więc pod tym względem React nie jest jakoś tam, powiedzmy, się nie wyróżnia, bardziej zewnętrzne narzędzia poszły mocno do przodu.

Natomiast jeżeli chodzi o unit testy, no to React od początku był nastawiony dość mocno na możliwości testowania, więc udostępnia i swoją bibliotekę testing library, czy dość mocno też rozwinięta jest biblioteka JASP, w której możemy testować. Czy za pomocą Snapshotów czy za pomocą JS DOM-a możemy to robić, a i też dobrą — to też zależy od kwestii gustów — ale dobrym rozszerzeniem, które mógłbym polecić jest, chociażby biblioteka Enzyme od Airbnb, która w ciekawy sposób pozwala na testowanie zachowania naszych komponentów, gdzie możemy sobie te testy zorganizować w taki sposób, że testujemy tylko jakiś komponent najwyższego rzędu albo gdy chcemy, możemy też potestować, co się dzieje w dół — odpowiednie argumenty przekażemy czy odpowiednio stan się będzie zmieniał, więc sam taki ekosystem już, jeżeli chodzi o testy jednostkowe, w Reakcie jest mega dojrzały.

Tu nie ma jakichś problemów związanych z tym, żeby w ogóle te testy rozpocząć. Tworząc nową aplikację już mamy wszystko zsetupowane, co jest fajne i przyjemne, bo w poprzednich wersjach różnie z tym było.

Czy testujemy aplikacje? Oczywiście, że testujemy. Przynajmniej powinniśmy. I one też dość szybko się uruchamiają, czy na feature branchach, czy przed deploymentem, także miło, szybko i wygodnie.

Tak powinno być! Jakiś czas temu, gdy to było legalne i konferencje offline się odbywały, to lubiłem sobie pójść od czasu do czasu na wystąpienia niekoniecznie związane z tym moim backendowym światem, ale też takie frontendowe. I wtedy, kiedy ktoś mówił o Reakcie, to jednocześnie słyszało się też coś o Reduksie.

Pytanie do ciebie właśnie o to zarządzanie stanem w aplikacji. Czym jest Redux i jak on się ma do React Hooks i do tego przechowywania stanu, o którym wspomniałeś?

Twórcy Recta zrobili sobie Reacta, parę dobrych lat temu i to była świetna biblioteka do tworzenia komponentów i do budowania za ich pomocą interfejsu, tylko tam możemy sobie poklikać. Warstwa prezentacji, ta warstwa obsługi zdarzeń działa po prostu od razu w Reakcie, natomiast sami twórcy w Reakcie zaczęli szukać jakiegoś sposobu na efektywne przekazywanie danych pomiędzy komponentami.

Ponieważ w Reakcie ten przepływ danych odbywa się z góry na dół, czyli od jakiegoś komponentu rodzica do podrzędnego albo do któregoś dziecka w tej strukturze. I jeżeli mamy taką strukturę, to jeszcze jest w miarę okej, da się to zrobić, natomiast jeżeli mamy komponenty, które sąsiadują ze sobą, dajmy na to ja klikam w jakimś komponencie, który jest odpowiedzialny za wyświetlenie strony głównej i chcę zrobić jakąś interakcję z komponentem, który ma mi wysunąć czy jakieś boczne menu, czy schować górny pasek czy dajmy na to ukryć stopkę, to to są komponenty niepowiązane ze sobą. Natomiast w jaki sposób twórcy Reacta szukali takiej drogi, aby zapewnić dostęp do danych w jakimś takim wspólnym obiekcie, wspólnym takim storze.

Wymyślili sobie fluxa, flux składał się z głównego pojemnika nazywanego store’em i różne komponenty, które były wpięte do tego store’a, nasłuchiwali, mogły po prostu pobierać dane, jak również wywoływać akcje z poziomu widoku.

Jeżeli na jakieś kliknięcie, na najechanie myszką ja odpalę akcję, to ta akcja zostanie przekazana do dispatchera, dispatcher fragment mojego globalnego obiektu z danymi zmodyfikuje pewien wycinek i te komponenty, które nasłuchują na te dane, na ten wycinek, dostaną tę informację jako propsy. A już w naturze Reacta, algorytmy Reacta zapewniają to, że jeśli komponent dostanie nowe propsy, to sam się przerenderuje na ekranie.

Pomysł więc ogólnie zacny i słuszny, natomiast poziom abstrakcji skomplikowania jest dość wysoki, moim zdaniem. Dużo czasu trzeba poświęcić, żeby jednak tego Reduxa dobrze opanować, no i też jak już się tego Redux opanuje, widziałem masę projektów, w których się go po prostu pcha na siłę, bo już jest. Bo już wiemy, jak z tego korzystać, co niestety bardzo przeładowuje nasze aplikacje.

Pomysł więc ogólnie zacny i słuszny, natomiast poziom abstrakcji skomplikowania jest dość wysoki, moim zdaniem. Dużo czasu trzeba poświęcić, żeby jednak tego Reduxa dobrze opanować, no i też jak już się tego Redux opanuje, widziałem masę projektów, w których się go po prostu pcha na siłę, bo już jest. Bo już wiemy, jak z tego korzystać, co niestety bardzo przeładowuje nasze aplikacje.

I w roku 2020, w którym sobie rozmawiamy, widać już trochę, że programiści nabrali lepszych praktyk i nieco bardziej patrzą teraz na rozwiązania oparte chociażby na Hookach, na zasadzie use reducer, to jest Hook, za pomocą którego nie potrzebujemy zewnętrznej biblioteki, jaką jest Redux, możemy to dotrzeć sobie do przekazywania na Hookach, możemy skorzystać z Context API, które zostało przypisane parę wersji wcześniej w Reakcie albo też przyglądać się, jak wygląda rozwój biblioteki Recoil, ona jest również rozwijana przez twórców Reacta, natomiast jest dużo lżejsza, jeżeli chodzi o wykorzystanie takiego globalnego stanu i dużo łatwiejsza w opanowaniu.

Natomiast nie jest jeszcze w takiej wersji produkcyjnej, więc sami twórcy Reacta już widzą, że troszkę tam chyba przekombinowali i coś się tutaj na pewno zmienia.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-098-react/

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store