Dlaczego React w 2020 roku jest wartą uwagi biblioteką?

Każdy, kto choć trochę orientuje się w realiach webdevelopmentu, słyszał o bibliotece React. Istnieje na rynku tak długo, że coraz częściej pojawiają się pytania – co dalej? Nadal jest warta uwagi, czy może zestarzała się? Jeżeli warto, to na czym skupić się najmocniej? Jaki kierunek powinien obrać junior, a jaki bardziej zaawansowany developer? Na te pytania postaram się odpowiedzieć w akapitach poniżej.

Pozycja Reacta w 2020 roku

Od razu może odpowiem na podstawowe pytanie – tak, warto uczyć się Reacta jeżeli jeszcze go nie znamy. Jeżeli tylko to chciałeś wiedzieć – przejdź do kolejnego, interesującej Cię sekcji. Jeżeli ciekawi Cię dlaczego tak sądzę, to poniżej parę argumentów, które za tym przemawiają.

React dalej deklasuje konkurencję pod względem popularności

Co z tego? Przekłada się na to, że jeżeli wiele osób go zna, to warto rozpoczynać nowe projekty w oparciu o niego. Prosta matematyka – jak będzie potrzeba więcej rąk do pracy, to łatwiej będzie nam zrekrutować kogoś, kto go zna niż Angularowca czy programistę Vue (choć oczywiście ich też jest całkiem sporo).

React Native nadal radzi sobie dobrze

Choć konkurencja na polu narzędzi do tworzenia aplikacji mobilnej coraz bardziej zagęszcza się, szczególnie patrząc na rosnącą popularność Fluttera, React Native nadal jest świetnym sposobem na niskokosztowe tworzenie rozwiązań pod wiele platform naraz. Łatwo nam się więc przebranżowić na mobile developera.

Jest praca, są pieniądze

Porównując statystyki największych portali branżowych, pracy w React oraz React Native zdecydowanie nie brakuje. Co ciekawe, jego popularność nie jest wprost proporcjonalna do ilości ofert i programiści korzystający z innych rozwiązań (Vue, Angular, a nawet leciwy Backbone) nie odstają aż tak bardzo (a nawet wcale, w zależności od regionu). Tak czy inaczej, pracy jest sporo i nie zapowiada się na to aby miało jej ubywać w najbliższych latach.

Co powinien umieć junior

Zanim zacznie przygodę z React

Osoba zaczynająca przygodę z programowaniem na froncie, najczęściej nie skupia się na rzeczywiście najbardziej optymalnej ścieżce nauki, a celuje w “fajnie” brzmiące technologie, interesuje się popularnymi rozwiązaniami. Niekoniecznie rozumiejąc po co są, jakie problemy rozwiązują i w jaki sposób.

Nie wchodząc więc w szczegóły, bo to temat na osobny artykuł – osoba zaczynająca swoją karierę powinna w pełni rozumieć i świadomie używać pętli, znać składnię ESNext, w podstawowym stopniu rozumieć asynchroniczność i pułapki z nią związane, nie mówią już o fundamentach, takich jak zakresy leksykalne, operacje logiczne. To oczywiście tylko i wyłącznie moja opinia, natomiast patrząc na kursantów, których miałem lub mam okazję uczyć, to takie jednostki z dużo większą łatwością odnajdują się w Reactowej rzeczywistości.

Oferty pracy z

Kiedy jest już na nią gotowy

W mojej opinii, najszybszym sposobem na zrozumienie konceptów Reacta, jest przerobienie swoich starych projektów. Jest z tym związana jedna ważna korzyść – sama logika, struktura aplikacji jest nam już znana, rozumiemy co się w niej dzieje. Możemy skupić się wyłącznie na przerzucaniu znanych nam funkcjonalności na sprytniejsze rozwiązania. Pomijamy ten irytujący etap, gdzie chcemy uczyć się narzędzia, a spędzamy czas na męczeniu się ze sprawami (na ten moment) pobocznymi.

Niezbędnymi elementami ekosystemu Reacta, która powinien zgłębić junior aspirujący do swojej pierwszej pracy lub zmiany biblioteki/frameworka są:

• Komponenty funkcyjne oraz klasowe

Celowo wspominam o obu, ponieważ z nimi spotkamy się podczas pracy, a te drugie są dość mocno deprecjonowane ostatnimi czasy. Komponenty funkcyjne od ponad roku dają nam możliwość zarządzania stanem, pracowania z efektami, co sprawiło, że przestały być tymi “prostymi/gorszymi”, ale klasowe wcale nie umarły. Dodatkowo nadal spotyka się głosy przemawiające za czytelnością starszego podejścia. To sprawa dyskusyjna, natomiast faktem jest, że jeszcze jakiś czas będziemy spotykać oba podejścia.

• Hooks, praca ze stanem, propsami, cyklami życia komponentu

Chodzi o wszystko z tym związane – destrukturyzacja, używanie useState, useEffect (który nie jest specjalnie prosty do opanowania przez początkujących), setState.

• Renderowanie list, warunkowe

W teorii prosta sprawa, natomiast można ją rozwiązać na kilka sposobów – warto wypróbować różne, porównać ich czytelność, wygodę użytkowania.

• React Router

Podstawowa biblioteka (nie zawarta w samym React), która pozwala na tworzenie SPA – jednostronicowej aplikacji, a mówiąc prościej, takiej apki, która nie wymaga pełnego przeładowania przy zmianie widoków.

Zobacz też

Frontend Od drobnego projektu po najpopularniejszą bibliotekę. Historia Vue

Co powinien wiedzieć bardziej doświadczony developer

Osoba, która położyła już palce na komercyjnym kodzie, rozumie JavaScript, HTML i CSS na poziomie średniozaawansowanym, powinna przyjrzeć się następującym zagadnieniom:

Poprawna granulacja

To nie jest żadna specjalna technologia, moduł czy trendy ciekawostka. To coś, co sprawia, że nasza aplikacja ma strukturę, w której łatwo się odnaleźć, nowi członkowie zespołu szybko się wdrażają, a utrzymanie jej nie jest drogą przez piekło.

Reużywalność, ale też skupienie na testowalności

Tutaj ścierają się dwa obozy – osób, które są za tworzeniem dużej ilości nawet podobnych do siebie komponentów, mających jednak jedno przeznaczenie. Wynika to z chęci utrzymania łatwości testowania poszczególnych komponentów, zmniejszenia ilości instrukcji warunkowych, które choć niezbędne, mogą być też powodem powstawania błędów i nieprzewidywalnego zachowania aplikacji (oczywiście tego da się unikać, ale nie jesteśmy nieomylni).

Zdecydowanie nie jestem zwolennikiem tworzenia 15-tu komponentów button’a, ale z kolei kombajn obsługujący 15 różnych scenariuszy w jednym pliku to równie, jak nie bardziej niebezpieczna skrajność.

Praca ze Storybook, atomic design

Jeżeli zaczynamy pracę nad projektem, który najprawdopodobniej mocno się rozrośnie (a nigdy tak naprawdę nie możemy tego wykluczyć) warto przyjrzeć się rozwiązaniu, którym jest Storybook. To narzędzie do składowania naszych komponentów oraz ich dokumentacji. Niejednokrotnie, wkraczając do projektu, który jest w fazie utrzymania, zdarzało mi się przez przypadek użyć innego komponentu, niż reszta zespołu miałaby w zwyczaju.

Wynikało to zwykle ze zbyt generycznych nazw lub odwrotnie – takich, które wydawały się pasować w sam raz. Storybook pomaga nam unikać takich problemów, testować komponenty w odizolowanym środowisku, ułatwia również konsultacje z działem UX/UI. Jest także świetnym sposobem na rozpoczęcie pracy z atomowym designem, czyli rozdzielaniem naszych komponentów na najmniejsze elementy – atomy, cząsteczki, organizmy.

Context API & Redux

Co prawda, na problemy dziedziczenia parametrów, dzielenia ich pomiędzy wieloma komponentami trafimy na dość wczesnych etapach pracy z Reactem, ale będąc praktykiem, powinniśmy mieć to solidnie opanowane – stąd Context API znalazło się w tym dziale razem z Reduxem. Warto też mieć świadomość, kiedy możemy poradzić sobie całkowicie bez używania tych rozwiązań (inversion of control) w najprostszych scenariuszach.

Styled components

Ciekawe, choć początkowo dość kontrowersyjne podejście do pisania styli naszych komponentów. Znajdują się one zwykle w tym samym pliku co komponent, w formie template stringa. Ich korzyścią jest możliwość pełnego wykorzystywania logiki dostępnej w JavaScript, możliwości używania globalnych theme’ów. Warto dać im szansę, jako alternatywa do modułów CSS, Sassa itp. Dodatkowo w pewnym stopniu wymusza na nas atomowe podejście wspomniane wcześniej.

Pozycje obowiązkowe na poziomie seniority

Co sugerowałbym wziąć na celownik osobom, które wszystkie wymienione wyżej aspekty pracy z Reactem w 2020 mają w małym palcu?

TypeScript

To po prostu kolejny krok w stronę uporządkowanego, bardziej “stabilnego” i przewidywalnego kodu. Oczywiście mamy w prop types, ale tak naprawdę nie spełniają one takiej samej roli co dodanie silnego typowania. Według mnie używanie typów jest jednym z podstawowych ruchów do pisania długoterminowo stabilnej aplikacji, krokiem niemal równie ważnym co pisanie testów. To po prostu pierwszy, teoretycznie prymitywny, ale jednak skuteczny filtr, który odsiewa najgłupsze błędy w implementacji. Świetnie nadaje się też do tworzenia modeli danych przychodzących z backendu.

Testy E2E

Od momentu, w którym miałem szansę uczestniczyć w projekcie w pełni otestowanym zarówno jednostkowo, jak i integracyjnie, zakochałem się w tym podejściu. Po x projektach, w których wiele rzeczy żyje własnym życiem, “nie rusza się ich, bo działa”, totalnej losowości, w końcu miałem okazję zobaczyć, że wcale nie musi tak to wyglądać. Początkowo wizja pisania takiej ilości testów, a co dopiero w metodologii TDD, wydaje się być karą, a nie przywilejem, ale po krótkim czasie widać jak mocno przekłada się to na stabilność aplikacji, ilość zgłaszanych bugów, czy po prostu – nasz spokój psychiczny.

Zobacz też

QA Każdego tygodnia wykonujemy 250 tys. testów. Jak wygląda praca testera w Ericsson

HOC

Higher order components to wzorzec mówiący, że powinniśmy stworzyć dodatkowe opakowanie na nasz komponent. Po co? W dużym skrócie, ma to służyć przeniesieniu części puchnącej logiki naszego komponentu (często jest to podstawowa walidacja) o jeden poziom wyżej. HOC to funkcja zwracająca przekazany do niej komponent lub coś całkiem innego – komunikat o źle przekazanych parametrach, komponent błędu itd itp. Bardzo przystępnie i szybko wytłumaczone jest to tutaj.

Dobre praktyki, wzorce projektowe

Chociaż powinno to być podstawą, rzeczą wypisaną w pierwszym dziale – dla juniorów, to nie oszukujmy się. Wiele wzorców, dobrych praktyk jest bardzo trudna do zrozumienia dla osoby bez doświadczenia komercyjnego. Choć są to często bardzo proste koncepcje, jak wspomniane wyżej HOC, bez wgryzienia się w kod, bez zetknięcia się z pewnymi problemami – brzmi to jak zwykły bełkot, który ciężko uznać za coś prawdziwie przydatnego. Zdecydowanie również zainteresować się tematem accessibility, który staje się coraz bardziej popularny, szczególnie za oceanem.

Czy to wszystko?

Wypisałem tutaj najistotniejsze z mojego punktu widzenia aspekty. Jest on jednak, jak to punkt widzenia, obarczony moimi doświadczeniami, specyfiką projektów, w których brałem udział – a nie prawdą objawioną. Bardzo chętnie poznam też Wasze opinie, które pozwolą przygotować rozwinięcie tego artykułu. Co zmieniło Waszą pracę na wygodniejszą? Z jakich błędów zdaliście sobie sprawę i chcielibyście przestrzec przed nimi resztę? Będę bardzo wdzięczny za wszelkie sugestie, a tymczasem życzę Wam owocnej, ciekawej nauki, która sprawia frajdę.

Polecamy także tekst pt. Dlaczego .NET w 2020 roku nadal jest warty uwagi?

Zdjęcie główne artykułu pochodzi z unsplash.com.