09 gru 2020 POIT #098: React
Witam w dziewięćdziesiątym ósmym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest React.
Dziś moim gościem jest Patryk Omiotek – programista z ponad 12 letnim doświadczeniem. Specjalista 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.
W tym odcinku o React rozmawiamy w następujących kontekstach:
- jakie były okoliczności powstania React.js?
- na czym polega programowania reaktywne?
- czy jest to framework czy biblioteka?
- jak wygląda jego popularność i miejsce na rynku pracy?
- jak może wyglądać przykładowa architektura aplikacji stworzonej z wykorzystaniem React’a?
- czym są i w czym pomagają React Hooks?
- do czego wykorzystywany jest Redux?
- jakie wzorce projektowe sprawdzają się w przypadku React?
- na ile umiejętności z React.js można wykorzystywać w React Native?
- jakie są najczęstsze błędy początkujących w React?
- jak React współpracuje z TypeScript?
- jaka będzie przyszłość React’a?
Zyro.com – do 81% rabatu
Zyro to intuicyjne narzędzie do tworzenia stron i sklepów internetowych. Dla słuchaczy podcastu na stronie https://zyro.tech/poit znajdziesz specjalną, limitowaną ofertę dzięki której zaczniesz korzystać z tego narzędzia o nawet 81% taniej w planach cenowych powyżej roku! Wykorzystaj kod rabatowy POROZMAWIAJMYOIT!
Subskrypcja podcastu:
- zasubskrybuj w Apple Podcasts, Google Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
- ściągnij odcinek w mp3
- poproszę Cię też o polubienie fanpage na Facebooku
Linki:
- Profil Patryka na LinkedIn – https://www.linkedin.com/in/patrykomiotek/
- Szkoła Reacta – https://szkolareacta.pl/
- Kanał Patryka na YouTube – https://www.youtube.com/channel/UCSYWHzGSL3nRJEkBMIfIEmA
Wsparcie na Patronite:
Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.
Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, która wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.
👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit
Pozostańmy w kontakcie:
- 📧 Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl
- 📩 Zapisz się na newsletter aby nie przegapić kolejnych ciekawych odcinków.
- 🎙 Subskrybuj podcast w lub
Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)
Transkrypcja podcastu
To jet 98. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o React. Przypominam, że w poprzednim odcinku rozmawiałem o drodze od developera do foundera.
Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/98.
Jeśli jeszcze tego nie zrobiłeś, to wystaw ocenę lub recenzję podcastowi w aplikacji, w której tego słuchasz.
Jestem fanem korzystania z odpowiednich narzędzi – nie inaczej jest też ze stronami www czy sklepami internetowymi. Chcę Ci dziś polecić Zyro, które znajdziesz pod adresem zyro.com.
Jest to serwis, dzięki któremu w szybki i prosty sposób stworzysz swoją stronę lub sklep. Z miesięcznym abonamentem w cenie kawy dostajesz możliwość wykorzystania wielu szablonów, ich personalizacji dzięki mechanizmowi przeciągnij-upuść oraz integracji z zewnętrznymi serwisami typy Facebook, Instagram czy Amazon.
Mało tego, dzięki wbudowanym mechanizmom AI dostajesz wspomaganie przy budowaniu marki Twojego biznesu. Strony tworzone przy użyciu Zyro są naprawdę szybkie. Działają responsywnie, a wszystko to można edytować nawet z wykorzystaniem telefonu.
Dla słuchaczy podcastu na stornie https://zyro.tech/poit znajdziesz specjalną, limitowaną ofertę, dzięki której zaczniesz korzystać z tego narzędzia o nawet 81% taniej w planach cenowych powyżej roku. Aby to zrobić skorzystaj z kodu POROZMAWIAJMYOIT
Co ważne, możesz już dziś skorzystać z tej oferty, a swoją stronę zacząć budować w Zyro w dowolnym czasie. Polecam rozwiązania, które sam sprawdziłem. Nie inaczej jest też w przypadku Zyro. Kreator jest bardzo intuicyjny.
Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty, będę to robił z sukcesem.
Już dzisiaj możesz mnie wesprzeć w tej misji zostając patronem na platformie Patronite. Wejdź na orozmawiajmyoit.pl/wspieram i sprawdź szczegóły!
Bardzo dziękuję moim obecnym patronom.
Nazywam się Krzysztof Kempiński i życzę Ci miłego słuchania.
Odpalamy!
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.
Powiedziałeś, że weryfikujesz wiedzę, umiejętności kandydatów w procesie rekrutacji. I o ile sam ze swojego doświadczenia mogę powiedzieć, że w takich backendowych rekrutacjach często pyta się o wzorce projektowe. Co prawda nieraz te pytania są zupełnie od czapy i odstają od realiów prawdziwego projektu, ale generalnie te pytania się zwykło stosować. Niektórzy twierdzą, że w tym świecie javascriptowym pytanie o wzorce projektowe jest trochę naciągane.
Jestem ciekawy, co ty o tym myślisz i czy to community zorientowane wokół Reacta wypracowało już jakieś wzorce, które na przykład są polecane, częściej stosowane, czy to jednak jest nadal dosyć duża swoboda?
Gdybym miał się skupiać tylko na aplikacjach frontendowych, to faktycznie zgodziłbym się z tym, że jako-takie wzorce, które znamy bardziej z architektury oprogramowania nie zawsze mają sens bycia. Ciężko powiedzieć, żeby w aplikacji frontendowej ktoś zrobił fasadę dla swojego API, to jest troszkę na styku albo już takiej komunikacji z backendem, albo już sam backend, jeżeli w Nodzie piszemy.
Gdybym miał się skupiać tylko na aplikacjach frontendowych, to faktycznie zgodziłbym się z tym, że jako-takie wzorce, które znamy bardziej z architektury oprogramowania nie zawsze mają sens bycia.
Natomiast jeżeli chodzi o aplikacje już stricte frontendowe, no to z takich bardziej znanych wzorców chociażby można co nieco posługiwać się niektórymi tylko. Czy to fabryka, gdzie musimy sobie stworzyć jakiś komponent, natomiast w samym świecie reactowym zostały wypracowane pewne rozwiązania, które nazywane są wzorcami. Nie są to może do końca te nazwy, które w jakiś sposób kojarzymy z oprogramowania, ale tak – sami twórcy Reacta kilka takich podają, chociażby niech to będą komponenty wyższego rzędu, które działają nieco podobnie jak funkcje wyższego rzędu w JavaScripcie, czyli nawiązując do wzorców, są to w pewien sposób dekoratory, które dają nam dodatkowe propsy albo dodatkowe metody do naszych komponentów, nie zmieniając ich zachowania.
Dużo też miejsca poświęca się, chociażby na wdrażanie do programistów, zwłaszcza tych, którzy dobrze się orientują w programowaniu obiektowym, aby stosować kompozycje w aplikacjach reactowych i nie używać dziedziczenia.
Jako ciekawostkę mogę powiedzieć, że gdy – w sumie teraz też – możemy pisać komponenty klasowo, natomiast w dokumentacji Reacta jest wprost napisane, że twórcy Reacta nie znaleźli ani jednego przypadku w grupie ich kilkuset komponentów, gdzie mielibyśmy rozszerzać nasz komponent. Gdy piszemy sobie klasowo w Reakcie, to rozszerzamy klasę component i nie ma uzasadnienia, aby nasz komponent rozszerzać innym komponentem, który napisaliśmy, inną naszą klasą – z tego względu, że bardzo dobrze faktycznie działa kompozycja, czyli w JSX bardziej przekazujemy, robimy taki komponent nadrzędny i tam przekazujemy w JSX definicję naszego innego komponentu, to działa świetnie, ale my na początku nie wierzyliśmy twórcom Reacta i postanowiliśmy sprawdzić to na własną rękę.
Jako ciekawostkę mogę powiedzieć, że gdy – w sumie teraz też – możemy pisać komponenty klasowo, natomiast w dokumentacji Reacta jest wprost napisane, że twórcy Reacta nie znaleźli ani jednego przypadku w grupie ich kilkuset komponentów, gdzie mielibyśmy rozszerzać nasz komponent.
I zrobiliśmy faktycznie – to był taki komponent grid, który przyjmował jakieś dane i to była odmiana tego grida. Zrobiliśmy takiego potworka, jak się później okazało i jednak się cofnęliśmy. Stwierdziliśmy, że twórcy Reacta jednak chyba wiedzą, co piszą!
W międzyczasie padło słowo React Native, chciałbym chwilę o tym porozmawiać, bo ustaliliśmy, że React czy React.js, bo znana jest też bardziej pod tą nazwą, to jest bardziej biblioteka. Ale React Native, ja bym to nazwał może frameworkiem albo nawet jakąś platformą, wręcz całą.
Na ile można wykorzystać swoją wiedzę, swoje doświadczenie nabyte właśnie w React.js, do tego, żeby tworzyć takie cross platformowe aplikacje z wykorzystaniem React Native’a? Czy masz okazję obserwować gdzieś takie spełnienie marzenia pracodawcy, który zatrudnia jednego developera i ten developer jest w stanie i zrobić aplikację webową, i aplikację mobilną, czy też mimo wszystko jednak ta specyfika jest trochę inna i specjalizacje się zarysowują?
Zgodzę się z tobą, że o React Native możemy mówić bardziej jak o takim systemie służącym do wytwarzania aplikacji mobilnych i ja zauważyłem, że znając Reacta w miarę gładko można przejść do React Native, ponieważ aplikacje oparte na Reakcie i aplikacje oparte na React Native wykorzystują tę samą bibliotekę.
Natomiast React w aplikacjach webowych jest renderowany przez inną bibliotekę React DOM, którą sobie zaczepiamy na jakimś elemencie, to może być jakiś diff i tych difów może być więcej, więc możemy tam więcej aplikacji nawet wpiąć, co raczej rzadko się stosuje, natomiast w React Native mamy bardzo dużo z tej biblioteki React, natomiast nie możemy korzystać chociażby z HTML-a. Nie możemy sobie więc tak bezpośrednio operować na HTML-u, tak stricte. Najpopularniejsze tagi dff, jest zamieniony na Vue i też stylowanie za pomocą CSS nie zadziała, więc tutaj może być takie pierwsze zdarzenie z Nativem.
Natomiast myślę, że podejście jest dość płynne, do czasu związanego, chociażby z optymalizacją czy z deploymentem, więc ogólnie React Native poszedł mega do przodu, porównując, chociażby z zeszłym rokiem. Progress, który zrobili jeżeli chodzi o taką nawet przyjemność tworzenia tych aplikacji jest ogromna, ale widziałem też sytuację w drugą stronę – gdzie osoby, które znają native’a, całkiem dobrze sobie w nim piszą, ciężko jest im się odnaleźć w Reakcie webowym, co mnie nieco zaskoczyło.
Natomiast myślę, że podejście jest dość płynne, do czasu związanego, chociażby z optymalizacją czy z deploymentem, więc ogólnie React Native poszedł mega do przodu, porównując, chociażby z zeszłym rokiem. Progress, który zrobili jeżeli chodzi o taką nawet przyjemność tworzenia tych aplikacji jest ogromna, ale widziałem też sytuację w drugą stronę – gdzie osoby, które znają native’a, całkiem dobrze sobie w nim piszą, ciężko jest im się odnaleźć w Reakcie webowym, co mnie nieco zaskoczyło.
Ale może faktycznie – do webowego trzeba mieć jakieś podstawy HTML-a i CSS-a i jeżeli chodzi o tworzenie takich cross platformowych projektów i ten mokry sen pracodawcy, o którym wspomniałeś, to faktycznie coś takiego istnieje i widzimy to wśród naszych klientów, z którymi współpracujemy, bardzo cenią chociażby znajomość Reacta wśród develperów chociażby z tego względu, że jak chcemy, to w sumie ten sam zespół może nam zrobić aplikację mobilną. Bo w sumie już znają naszą domenę, nasz biznes, API pewnie będzie podobne, z którego korzystają, no to co tam zrobić taką apkę mobilną.
Pamiętam, że też uczestniczyłem w takim projekcie, gdzie najpierw dla klienta robiliśmy wersję webową, a później tworzyliśmy właśnie aplikację mobilną. Tylko że to było półtora roku temu i bardzo współczuję devopsom, którzy mieli już dużo wyzwań, jeśli chodzi o deployment na Androida i na iOS-a. Z teorii to miało być jeden kodzik, ale zaczęły się różne rozjazdy. Niby teraz jest lepiej, ale już chyba od roku nic w Native nie pisałem. Słyszałem dużo dobrego, na pewno. Ale mogę potwierdzić, że faktycznie klienci cenią coś takiego i wykorzystują tę wiedzę zdobytą w Reakcie webowym, aby też tworzyć aplikacje mobilne.
Tak, coś w tym jest. W projekcie, w którym ja teraz jestem, jest osobna osoba, która zajmuje się React Native’em tworzenia aplikacji mobilnej, co prawda frontend developerzy, którzy na co dzień programują też m.in. w Reakcie są w stanie od czasu do czasu jakiegoś buga załatać, ale generalnie przynajmniej ja tutaj obserwuję na tym swoim poletku, że to jest taka dodatkowa specjalizacja, która zaczęła się coraz mocniej wykształcać i robić taka bardziej wyraźna.
Wydaje mi się, że powstanie taka osobna dziedzina czy specjalizacja, bo po prostu te rzeczy będą się rozwijały trochę w jednym kierunku, ale mimo wszystko jednak te różnice będą się pojawiały. Jestem ciekaw, zobaczymy.
Zgodzę się z tobą. Chociażby to, co ja widziałem, o czym wspominałem, że osobie z React Native’a było ciężko odnaleźć się w samym Reakcie, więc tam jest bardzo dobrym developerem, natomiast prawdopodobnie, mimo że ta baza jest w miarę podobna, to będziemy mieli dwie osobne specjalizacje za jakiś czas.
Dokładnie. Dużo się mówi o Reakcie jak o takiej popularnej bibliotece, popularnym kierunku rozwoju kariery. Też wiele osób, chcąc rozpocząć swoją przygodę jako programista, decyduje się na specjalizację frontendową, na Reacta. Jestem przekonany, że słucha nas teraz sporo osób, które myśli, żeby się Reacta nauczyć Stąd moje następne pytanie do Ciebie – jakie są najczęstsze błędy, jakie popełniają programiści w Reakcie, jakieś takie anty patterny, które widzisz, a których się nie powinno stosować?
Jeżeli chodzi o anty patterny, które są wykorzystywane w Reakcie, to jest coś, z czym zwłaszcza początkujący mają problem. Właściwie wybór, czy korzystamy z tych klas czy korzystamy z Hooków.
Jednym z takich anty patternów to jest mieszanie tego kodu. Rozumiem, że osoby początkujące, najfajniej, żeby sobie sprawdziły trochę jak klasowo się pisze, tym bardziej dla osób bardziej z backendu przechodzących czy uczących się programowania opartego na klasy, to może dla nich wydawać się fajniejsze, łatwiejsze, natomiast co mogę poradzić to wzięcie większej uwagi na naukę, jeżeli chodzi o Reacta – o wykorzystanie Hooków i podejścia funkcyjnego. To może nie jest jakiś anty pattern, ale na pewno osoby początkujące mają tutaj dużą – wiele pytań zawsze się pojawia, klasy czy Hooki? Jeżeli już miałbym coś wybrać, to jednak dla dzisiejszych słuchaczy mogę polecić raczej nastawienie się na Hooki, a kolejne rzeczy, z tego, co ja widze, to takie przeładowywanie na samym starcie już naszej aplikacji.
Sam prowadząc czy szkolenia czy różne zajęcia, widzę, że bardzo często osoby chcą już, żeby ich aplikacja frontendowa zaczęła wyglądać po chwili pisania kodu. Importuje tam więc różne, gotowe biblioteki, czasami Bootrstapa nawet, czasami Material-UI i korzystają z komponentów, które te biblioteki dostarczają bez dobrej znajomości, jak właściwie React działa, jak działa JSX, czym są propsy, jak działa stan, czym są metody cyklu życia. Widzę, że niektóre aplikacje działają, nawet fajnie wyglądają, ale jak się zajrzy pod maskę i zada się parę pytań, to się okazuje, że było to robione metodą copy-paste, natomiast jakaś prośba o modyfikację już powoduje problemy.
Dla osób początkujących mam taką gorącą prośbę, żeby tego nie robić, żeby najpierw przyswoić sobie te elementarne rzeczy i potem faktycznie zaczną się pojawiać już takie antywzorce na zasadzie – tutaj zaczniemy pewnie źle dobierać klucze, korzystać z indeksów zamiast z identyfikatorów z baz. Później prawdopodobnie pojawią się problemy z bindowaniem zdarzeń, często, chociażby w funkcjach renderujących osoby początkujące tam sobie bindują zdarzenia, co nie jest do końca złe, natomiast będzie w jakiś sposób wpływało na wydajność naszej aplikacji. No i kolejna rzecz związana z tym, jak właśnie nasze komponenty rozkładać w systemie – i jak je stylować.
Tutaj odpowiedź jest prosta – próbuj, pytaj się i jeszcze raz próbuj, bo React nam tego nie narzuci. Jest kilka sprawdzonych rozwiązań, natomiast tu trzeba na własnej skórze się trochę przekonać. Tak jak wspominałem w innej części rozmowy, akurat i architektura w Reakcie i stylowanie to są tematy, gdzie podejść mamy naprawdę dużo. Chociażby stylowanie – teraz mogę, chociażby 6 sposobów wymienić, części osób to pasuje, a części nie, więc warto po prostu kilka różnych podejść, przetestować, tym bardziej że tak jak mówię – to nie jest narzucone, a jednemu zespołowi może jeden sposób odpowiadać, innemu ten piąty albo szósty.
Rozumiem. To żeby nie było tak prosto, dołóżmy jeszcze kolejny klocek. Sporo się mówi ostatnio o TypeScripcie, takiej nadbudowie, rozszerzeniu JavaScriptu o typy. Jakie to ma przełożenie na Reacta? Czy takie połączenie Reacta i TypeScriptu to jest coś, co obserwujesz – coraz częściej się pojawia, tutaj też TypeScript będzie wchodził coraz bardziej na salony?
Mogę powiedzieć na starcie dla osób, które nie korzystają w ogóle z Reacta czy z Angulara, to mogę powiedzieć, e w Angularze TypeScript jest po prostu wbudowany od razu, więc gdy chcesz pisać w Angularze, powinieneś, powinnaś pisać w TypeScripcie. Jest to taki super set z szóstki, czyli język bardziej nastawiony na statyczne typowanie. Osoby, które mają jakieś doświadczenie w backendzie lub w Javie, to Angular im często bardzo pasuje pod takie rozwiązanie frontendowe.
Natomiast React korzysta z czystego Javascriptu, nie ma tam TypeScripta jako domyślny język pisania, natomiast jak najbardziej można go sobie dokonfigurować i już create React app, czyli taka aplikacja, za pomocą której tworzymy pierwsze projekty w Reakcie, posiada bardzo fajną i łatwą integrację z TypeScriptu. Natomiast jeżeli chodzi o wykorzystanie, no to tak powoli w świecie reactowym, może nawet trochę szybciej zaczyna się zapalać developerom lampka, ze w sumie ten TypeScript możemy również w sumie wykorzystać w Reakcie. Część osób oczywiście ma co do tego zastrzeżenia, bo jak statyczne typowanie w JavaScripcie to jest coś nienaturalnego dla języka, tym bardziej że pod spodem i tak to jest zamieniane na kod javascriptowy. Natomiast to trochę zależy od podejścia, w jaki sposób chcesz pisać.
Na pewno TypeScirpt da ci narzut kodu, będzie bardziej skomplikowany, jeśli chodzi o korzystanie z jakimiś innymi, zewnętrznymi bibliotekami, ale na pewno też już na takiej warstwie kompilacji, można powiedzieć, dużo można błędów wyłapać, gdzie javascript dla wielu osób to jest plus, a dla drugiej grupy to jest minus, jest językiem dynamicznym, bez statycznego typowania, gdzie możemy przepisać wszystko i właściwie wszystko nadpisać praktycznie w dowolnym momencie, no to TypeScript jednak będzie nas trochę pilnował. Raczej słyszę dobre opinie w świecie reactowym – jak już ktoś w Reakcie zasmakował TypeScripta, no to raczej nie wyobraża sobie projektów bez TypeScripta. Także oczywiście można też robić apki bez, można z, próg wejścia jest na pewno trochę wyższy, ale też potem można spać nieco spokojniej, jeżeli ma się TypeScripta w projekcie.
Okej. JavaScript czy też TypeScript załatwia nam w dużym stopniu logikę aplikacji. Wiadomo, że na tym się nie kończy nasza aplikacja, frontend nie zamyka. Jakich praktyk czy też podejść używa się, żeby z kolei nasza aplikacja jakoś wyglądała? Jak się styluje aplikacje z wykorzystaniem Reacta?
To już trochę zależy, co chcemy zrobić. Jeżeli chcemy stworzyć sobie bibliotekę komponentów, swoją własną, z której będziemy korzystali potem czy w tym projekcie, czy to ma być takie Monorepo, z którego będziemy korzystali w wielu, różnych projektach, no to w tym podejściu często się sprawdza raczej JavaScript i CSS, czyli bardziej pisanie CSS-u za pomocą JavaScriptu.
W JavaScripcie tworzymy obiekty i one mają nam odwzorowywać właściwości CSS-owe, które będą przekazane potem do naszego obiektu.
Plusy są, chociażby takie, że to jest czysty JavaScript, więc możemy za pomocą zwykłego języka sobie zdefiniować paletę kolorów, mixiny, breakpointy i potem po prostu importować w tych miejscach, gdzie jest to potrzebne.
Natomiast gdy już tworzymy komponenty korzystające z naszej biblioteki czy po prostu komponenty, które będą wykorzystywane w aplikacji, jakieś bardzo specyficzne, pod projekt, dajmy na to jakiś grid z użytkownikami czy jakąś listę, no to wówczas podejść jest sporo. Trochę też zależy od zespołu, co zespół sobie wybierze, ale możemy wystartować od zwykłych CSS-ów, bo w Reakcie to jest od razu dostępne. Czyli można zaimportować pliczek CSS-owy, można out of the box praktycznie korzystać z SaaS-a, trzeba tylko note SaaS-a doinstalować do projektu, więc to już są dwie drogi, to się sprawdza przy osobach, którym fajnie korzysta się z SaaS-a i mają to w miarę dobrze opanowane.
My również możemy tam korzystać z JavaScript i CSS. Dużą popularność, z tego, co widzę, zyskuje w sumie post-CSS, który jest w Reakcie wbudowany. Nie musimy niczego instalować, a daje nam właściwie takie możliwości jak SaaS, więc o jest czwarty sposób. Znane są też biblioteki zewnętrzne, które możemy doinstalować, chociażby z tide components, który daje nam mega możliwości, mianowicie możemy pisać tam za pomocą składni CSS-owej, ale wykorzystywać JavaScript. Czyli możemy tam również napisać sobie takiego CSS-a, korzystając ze składni, a zaimportować kolorki, breakpointy, możemy też tworzyć wrappery na nasze komponenty, możemy robić rozszerzenia i side CSS-y bardzo często są wykorzystywane w projektach, ale też są inne rozwiązania jak tubemint CSS w połączeniu ze style components. To daje nam już taki zdefiniowany zestaw klas, gdybyśmy nie chcieli swojego stylowania tworzyć do tworzenia, chociażby layoutu czy tworzenia breakpointów.
To jest tylko część, to co możemy zrobić, możliwości jest naprawdę wiele i w każdym projekcie trochę coś innego pewnie się sprawdzi.
Do wyboru do koloru wobec tego! Jak będzie wyglądała według ciebie przyszłość Reacta? Czy takie nowe biblioteki, frameworki, nowi gracze jak na przykład Vue są w stanie zagrozić pozycji Reacta według ciebie?
Niedawno wyszła nowa wersja Vue, Vue ma też fajną społeczność. Natomiast jeżeli chodzi o to, żeby zagrozić… Wydaje mi się, że do końca może nie. Część developerów może przejdzie sobie do Vue, ponieważ Vue jest dość mocno wzorowany na Reakcie, ale twórcy poszli w stronę frameworka, więc wzięli też fajne rzeczy, które w Reakcie im się podobały, dopisali to co według nich by było fajne, więc jeżeli ktoś szybko chciałby stworzyć aplikację, to myślę, że Vue jest fajnym rozwiązaniem, natomiast tutaj ciężko odpowiedzieć, czy jakieś inne rozwiązanie zagrozi, ponieważ jak ja zaczynałem przygodę z Reactem, to myślałem, że pewnie rok, półtora w tym poprogramuję, a potem wyjdzie jakieś nowe rozwiązanie. Natomiast wyszło tak, że i Angular, i React, i Vue to są już rozwiązania na tyle dojrzałe, że i branża bankowa z tego korzysta.
Jak oni z tego korzystają, no to raczej te rozwiązania będą przez długi okres jeszcze utrzymywane. Zobaczymy jeszcze, co przyniesie rozwój web komponentów natywnych w samych przeglądarkach, jak to się będzie odbywało. React wypuścił niedawno wersję siedemnastą, która nie przyniosła żadnych, nowych feature’ów. Tam twórcy przepisali parę rzeczy, natomiast będziemy obserwowali, jak ta wersja osiemnasta też się będzie zachowywała, więc na razie nowych smaczków nie ma i też trochę ciężko sobie wyobrazić, czy nowe rozwiązania zyskają takie duże community, duże wsparcie. Zobaczymy.
Mnie się wydaje, że w perspektywie co najmniej paru lat najbliższych jeszcze z Reactem będziemy mogli spokojnie korzystać.
Okej. Zobaczymy, co wobec tego przyszłość przyniesie. Bardzo dziękuję za rozmowę, za wprowadzenie do Reacta. Myślę, że nie tylko mnie rozszerzyłeś spojrzenie, ale też tym osobom, które myślą o tym, żeby douczyć się Reacta, a programują na backendzie, a coś innego ich interesuje albo chcą w ogóle rozpocząć swoją karierę. Myślę, że to też jest dobry kierunek.
Jeszcze raz wielkie dzięki za tę rozmowę dzisiejsza i powiedz proszę na koniec, gdzie cię można znaleźć w internecie, jak można się z tobą skontaktować?
Dzięki wielkie również za rozmowę! W internecie możecie mnie znaleźć wpisując w Google Patryk Omiotek, czy na Facebooku, LinkedInie, czy Instagramie. Z Twittera raczej rzadziej korzystam, ale też zaglądam.
Świetnie. Oczywiście wszystkie linki dodam do notatki tego odcinka. Jeszcze raz bardzo dziękuję.
Do usłyszenia, cześć!
Dzięki również, do usłyszenia, hej!
To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. React to bardzo popularne rozwiązanie w świecie frontendowym. Mam nadzieję, że teraz lepiej rozumiesz, skąd ta biblioteka się wzięła i na jakich podstawach opiera swoje działania.
Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl
Jeśli doceniasz to, co robię, wesprzyj mnie na Patronite. To taka platforma, na której wspierasz twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie.
Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.
Jeśli natomiast spodobał Ci się ten odcinek i nie chcesz przegapić kolejnych epizodów, zasubskrybuj go w swojej aplikacji podcastowej. Jeśli nie wiesz, jak to zrobić, wejdź na stronę porozmawiajmyoit.pl/subskrybuj.
Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o React.
Zapraszam do kolejnego odcinka już za dwa tygodnie! Będzie to ostatni odcinek w tym roku, w którym z moim gościem będę podsumowywał ten wyjątkowy 2020 rok w świecie IT. Cześć!