Techniki Zaawansowane
6 godz. 6 min · ReactJS · Full-stack i Programowanie
Adam RomanskiFrontend developer & YouTube CreatorJeden z pierwszych i najbardziej popularnych wzorców w React, który przez lata był traktowany jako najlepszy sposób na wydzielanie logiki z komponentów i współdzielenie jej w wielu miejscach aplikacji. W kursie na przykładzie dowiesz się w jaki sposób można wykorzystać HOC, a także jak łączyć je ze sobą tworząc bardziej zaawansowane struktury.
Obecnie Render Props jest jedną z najczęściej wykorzystywanych praktyk pozwalającą, podobnie jak HOC, na tworzenie abstrakcji, z których możemy czerpać dane lub zachowania potrzebne w naszych komponentach. Na pierwszy rzut oka Render Props mogą przerażać, ale spokojnie – zaczniemy od prostego przykładu, który pozwoli Ci zrozumieć, że nie ma się czego bać.
Hooks to temat niezwykle ciekawy i populary, ale rzadko poruszany w sposób bardziej zaawansowany. W tym kursie dowiesz się nie tylko jak używać takich hooków jak useState, useReducer, useEffect, useContext czy useRef, ale też jak napisać swoje własne hooki, które niesamowicie uprzyjemnią pracę z Reactem.
Compound Components to prawdziwa "ciężka artyleria" Reacta – stosowana w zadaniach wymagających sporej złożoności. Ewoluowała przez lata i kiedyś zawsze spotykana była w formie klas, natomiast w tym kursie proponujemy nieco lżejsze podejście. Dowiesz się jak wykorzystując hooki możesz stworzyć Compound Component wyłącznie przy użyciu komponentów funkcyjnych.
Testy to hasło, które potrafi wzbudzić lęk u osób uczących się Reacta, lub jakiejkolwiek innej technologii. Rzadko kto jednak mówi to głośno – testy są przyjemne! Wystarczy tylko zrozumieć w jaki sposób środowisko testowe działa i jakimi rządzi się zasadami. Przerobimy to wszystko wspólnie, a na koniec kursu przekonasz się, że to faktycznie ciekawe i przyjemne zagadnienie.
W kursie przygotowana jest też garść dobrych praktyk, które pozwolą Ci spojrzeć krytycznie na niektóre fragmenty kodu i ulepszać je w taki sposób, aby stanowiąc część większej całości miały więcej sensu i wdzięku. Dowiesz się czym jest Single Responsibility Principle, jak wydzielać odpowiednio logikę z komponentów i paru innych ciekawych wskazówek.
Ten kurs został stworzony z myślą o programistach swobodnie poruszających się po podstawach i nieco bardziej skomplikowanych partiach Reacta, ale nadal czujących, że brakuje im czegoś, aby wynieść swoje aplikacje na jeszcze wyższy poziom. Rzeczy związane z zaawansowanym JavaScriptem będziemy tu wykorzystywać intuicyjnie, bez zbędnego tłumaczenia, dlatego zanim przystąpisz do tego kursu, upewnij się, że treści React od Podstaw oraz React w Praktyce są dla Ciebie jasne i zrozumiałe.
16.8.x
Cześć skoro przypomnieliśmy sobie już jak działa jest to teraz
myślę że możemy spokojnie pożegnać się z tym testem nie będziemy z niego więcej korzystać
napiszemy zaraz swoje testy i zaczniemy naukę react testing library która pomoże
nam właśnie w testowaniu komponentów stwórzmy sobie jakieś najprostszy komponent
na świecie niech to będzie na przykład input w tym inpucie
stwórzmy sobie input js oraz
input test js i tutaj bardzo
ważna uwaga jak działa npm test skąd
on wie jakie my mamy testy skąd on wie gdzie szukać tych testów i dlaczego
właśnie znalazł input test wynika to z bardzo prostej rzeczy po prostu konfiguracja
jest'a działa w taki sposób że szuka za pomocą regexa wszystkich
plików które mają test w nazwie czy to będzie test js czy test jsx
czy na przykład spec też chyba będzie działał
zaraz zobaczymy bo to jest druga konwencja której też się
używa spec tak też się wyszukuje ale na przykład jakbym
nazwał sobie ten input grażyna
js już tego nie znajdzie nie wiem czemu tak się
przywiązałam do tej grażyny ale to jest taki fajny przykład więc zostajemy przy test test nam
się pojawia oczywiście failuje ponieważ ani komponent ani test nie zawierają
nic ale to dobrze za chwilkę sobie to naprawimy i tutaj tak naprawdę będziemy uczyć
się powoli dwóch rzeczy pierwszej to oczywiście react testing
library a drugiej to test driven development i
tutaj podkreślam to będzie raczej taka przygoda z test driven development to
nie jest kurs poświęcony wyłącznie temu i też nie uważam się za jakiś autorytet
w tej dziedzinie stosuje to wtedy kiedy mogę natomiast nie jestem ekspertem od tego
i pokażę ci jak ja tego uzywam natomiast nie wykazuje się
tutaj żadnym takim dogmatycznym podejściem że zawsze trzeba stosować test driven development czasami
odnajduje takie sytuacje kiedy łatwiej jest mi najpierw napisać komponent a później
dopiero test natomiast teraz sobie zaczniemy właśnie od takiego podejścia które
jest takim właśnie klasycznym podejściem jeśli chodzi o test driven development czyli najpierw piszemy failujące
testy później piszemy kod który spełnia te testy później
dopisujemy kolejne testy które sprawiają że zaczynają failować i później
znowu dodajemy nasz kod w międzyczasie to wszystko jeszcze refakturując
żeby po prostu wyglądało lepiej przy okazji nie psując dodatkowo testów
łatwiej to będzie jeśli pokażę ci to po prostu na przykładzie przy
okazji oczywiście zachęcam cię do tego żeby otworzyć sobie już teraz dokumentację
testing library ja mam na przykład otwarty teraz na
api dla reacta bo tutaj będzie nam się to przydawać tutaj mamy wiele metod
z których będziemy sobie korzystać i które ich definicje na pewno pomogą nam w zrozumieniu
tego czym one są a dodatkowo jeszcze odpal sobie jest
dom to też jest część testing library tutaj mamy takie specjalne matchery
które bardzo nam pomogą w tym żeby dobrze testować nasze komponenty i też robić to
naprawdę niezwykle łatwo więc teraz przejdźmy sobie do naszego testu
zaimportujemy tutaj reacta ponieważ podobnie jak w komponentach reactowych
tu również wykorzystujemy jsx podczas testowania piszemy sobie jakieś tam komponent
i to już jest jsx więc musimy mieć reacta zaimportowanego
żeby po prostu nasz test działał przy okazji jeszcze za importujemy sobie
metodę render z testing library i
jest to i do napisania naszego pierwszego testu i tutaj jeszcze
jedna taka ciekawostka ponieważ będziemy tutaj pisać pewnie kilka testów
w ostateczności gdzieś tam na końcu wyląduje pewnie z trzema czterema różnymi testami i
będziemy mieć tutaj kilka znowu tutaj te importy będziemy
mieć tutaj kilka tego typu rzeczy na przykład it
rangers properly i tutaj masz teścik
i pewnie ich będzie tak kilka tutaj
i generalnie łatwo można zrobić taki śmietnik sobie w tym
ponieważ jak to wytestujemy teraz jak puścimy to sobie
w konsoli to mamy tutaj właśnie kilka takich nazw ale one jakbyśmy
mieli 15 takich testów to będzie dość ciężko żeby to wszystko odczytać i
możemy tutaj dodać jeszcze jedną taką rzecz jedną metodę która nazywa się describe
i ona też jest jakby częścią jesta i ona pozwala nam
na grupowanie naszych testów to znaczy jeśli tutaj piszemy sobie input component
i wewnątrz tej funkcji którą podajemy tutaj ponieważ konstrukcja
jest dokładnie taka sama jak tego it jeśli teraz to wkleimy sobie do
wewnątrz to będziemy mieć ładną grupę testów ładnie tutaj
wciętą
i to wklimy tutaj to to również zostanie ładnie wcięte więc to jest takie fajne po
to właśnie żeby grupować sobie nasze komponenty więc pewnie gdzieś tam po drodze będę
też to stosował tak żebyś wiedział wiedziała jak to działa i po co to
robię a teraz usuwamy sobie już te wszystkie absurdalne testy i napiszmy
jeden konkretny więc zacznę sobie od describe input
component i to jest też fajne w tej nazwie jak tutaj
wpiszę właśnie descrive opisujemy co będziemy tak naprawdę testować
i później korzystając z tego z tej metody it na przykład renders
properly można to czytać jako takie jedno zdanie czyli input component na
przykład przecinek i tu renders properly więc to tak po angielsku już nawet brzmi
sensownie że tworzy jakąś historię że wszystkie te testy są jakąś taką
historię którą opowiadamy o tym komponencie i taką najprostsza rzeczą którą na początku
moglibyśmy sobie sprawdzić w naszym komponencie to czy on renderuje
nam input element stworzymy sobie tutaj funkcje strzałkową
i teraz najpierw napiszę fragment kodu i później ci wytłumaczę o co w niej chodzi okej
napisałem fragment kodu i nasz test zaczął wariować czyli tak jak przewidywaliśmy
najpierw piszemy failujący test później będziemy go naprawiać czym jest to co tutaj wpisałem
jest to getter pamiętasz jak w poprzedniej lekcji próbowałem
wyciągnąć z kontenera do którego montowaliśmy naszą za pomocą
query selectora wtedy to wyglądało tak div query
selector kropka app natomiast
react testing library daje nam możliwość wykorzystywania właśnie
takich getterów takich jak to oni nazwali queries do tego żeby
pobierać różne elementy z naszej aplikacji i możemy to robić za pomocą
na przykład label text czyli labelki
przypiętej do inputa możemy za pomocą placeholder text za
pomocą samego tekstu czyli na przykład jeśli mamy jakiś nie wiem tytuł albo
paragraf to możemy wpisać tekst i po nim właśnie złapać jakiś element przy
pomocy alt text jeśli mamy do czynienia z obrazkiem
i mamy tutaj naprawdę jeszcze kilka rzeczy zachęcam do tego żebyś teraz się z tym zapoznał
zapoznała natomiast ja wpisałam tutaj test
id i będziemy z tego trochę korzystać w tym
kursie ponieważ uważam że jest to taki bardzo fajny kierunek testowanie elementów
zaraz pokażę ci jak możemy wykorzystać te test id w naszym
react'cie żeby nasz test znalazł nasz element i tutaj
jeszcze takie słowo wyjaśnienia bo jak widzisz ja destrukturyzuję
sobie to get by test id z funkcji render ponieważ to funkcja
render zwraca nam obiekt w którym mamy dostępne te wszystkie narzędzia tak
to działa po prostu że możemy tutaj sobie po przecinku wymieniać co w danym tekście będzie
nam potrzebne i właśnie tutaj stąd wyciągniemy sobie to test id
składnia na początku może dziwna ale jest bardzo bardzo przydatna bo nie musimy tego importować
na przykład w tym miejscu więc jest to super więc napiszmy teraz
sobie jeszcze na szybko taki test w którym będziemy używać get by test
id i tutaj wewnątrz sobie piszemy input
na przykład sample input
i teraz skorzystamy jeszcze z drugiej paczki tutaj mamy jest dom
i tutaj jest na przykład taki matcher który się nazywa to be in the document i
to jest właśnie matcher który sprawdza czy to co wpisaliśmy sobie wewnątrz
tutaj expecta znajduje się w ogóle naszym dokumencie czy to w ogóle zostało zamontowane
jak
to wpiszemy to nasz test nadal failuje wynika to po prostu
z tego że nawet nie zaimportowaliśmy jeszcze naszego komponentu więc teraz odpalmy
sobie nasz komponent tutaj na dole zaimportujemy sobie
do niego reacta zauważ że ja to piszę w osobnym pliku nie piszę tego
w tym samym pliku żeby ci się nie pomyliło stworzę
sobie tutaj consta którego nazwę input to jest funkcja strzałkowa która
zwraca nam input export
default i teraz importuje sobie ten input w taki
sposób i teraz zauważ co się stało zmienił nam się błąd
w naszym teście teraz mamy unable to find element
by data test id sample input i to właściwie musimy
zawrzeć w naszym elemencie tutaj jak pewnie wiesz w
htmlu mamy dostęp do takich customowych jakby nazw
które możemy sobie dodawać jako twórcy jako programiści data
i tutaj możemy wpisać cokolwiek data roman przykład cokolwiek i
react-testing-library wykorzystuje właśnie data test id po
to żeby łatwiej można było łapać dane elementy i jest
to takie id stworzony wyłącznie na potrzeby testów
ono nic nie robi w samej aplikacji jak widzisz
po wpisaniu tego data id nasz test znalazł ten element i
powiedział słuchaj mamy faktycznie coś takiego test przechodzi i teraz dlaczego
tutaj na przykład nie wpisujemy nie wiem klasy i nie łapiemy sobie w klasie dlatego
że twórca tej biblioteki czyli kent c dodds tłumacząc
jakby dlaczego tak to stworzył mówił że on chciał stworzyć
bibliotekę która pozwala na testowanie komponentów w taki sposób w jaki testują
go użytkownicy więc prawie wszystkie metody które przed chwilą ci
pokazywałem wszystkie te queries get by name get by text
by placeholder to są rzeczy które są takie bardzo wizualne
to znaczy jeśli widzimy placeholder na przykład name no to po nim będziemy sobie
łapać nasz element i one wszystkie właśnie dotyczącą tego jak użytkownik by
na to patrzył natomiast ten selector jako jedyny to jest takie powiedzmy oldschoolowy
selector który właśnie pozwala na łapanie nam po czymś po czym
tak naprawdę użytkownik nie będzie łapał mam na myśli
jakby identyfikowanie danego komponentu więc jeśli użytkownik wchodzi na naszą stronę
i chce wpisać swoje imię w inpucie name no to będzie szukał sobie
placeholdera który się nazywa name natomiast my jako programiści
możemy jeszcze sobie stworzyć taką właśnie takie metadane które pozwalają nam
łatwiej znaleźć ten element bez konieczności na przykład ustawienia placeholdera jeśli
tego placeholdera nie ustawiamy akurat na danym elemencie jeśli się zastanawiasz
czy tego typu podejście na przykład nie zwiększy rozmiarów naszej aplikacji no bo to faktycznie
będzie kilka bajtów więcej tutaj jednak piszemy sobie jakieś literki naszym kodzie i one
przechodzą do naszej aplikacji no to faktycznie może będzie
to trochę więcej ważyło natomiast nie jest to w żaden sposób nie wiem
istotne z punktu widzenia aplikacji myślę że biblioteki
które wykorzystujemy w react'cie dużo więcej
ważą niż te kilka bajtów pamięci które zajmiemy poprzez właśnie tego typu id
natomiast jeśli mamy jakiś taki paniczny strach przed zaśmiecanie domu
tego typu rzeczami i w jaki sposób chcemy uniknąć tego
żeby to w ogóle poszło na produkcję to możemy to usuwać na etapie budowania
projektu przy pomocy plugina do webpacka szczerze mówiąc
nie widzę żadnego problemu żeby tego typu dane mogły iść na produkcję i po
prostu sobie wisieć w aplikacji ale żeby jeszcze lepiej ci wytłumaczyć
jak działają te wszystkie właśnie gettery te queries jak oni to nazywają to wykorzystajmy
sobie jeszcze jeden na koniec tej lekcji załóżmy że chcemy właśnie
przez by placeholder test o weźmiemy
sobie to czyli chcemy złapać nasz input przez plateholder napiszmy
sobie failujący test expect get by musimy
to zaimportować get by placeholder tekst
wpiszmy tutaj name to be in the
document i
znowu dostajemy tutaj błąd że nie ma czegoś takiego wywalmy sobie ten
data test id i wpiszmy tutaj placeholder i
przekornie wpiszmy name wielkimi literami i jak
widzisz test nie przechodzi dlatego że napisaliśmy tutaj uppercase'm a szukamy
lowercase natomiast możemy jeszcze wykorzystać regex i
dodając po regex'ie literkę i czyli case-insensitive będziemy
mówili słuchaj nieważne co jest napisane jakimi literami czy to jest pokemonem napisane
jak nieważne to nadal będzie łapać
ponieważ w tym momencie to name może być właśnie
uppercase lowercase może być naprzemiennie to zawsze będzie łapać chodzi tylko
o to żeby te literki się zgadzały więc
jeśli chcemy to możemy sobie szukać elementów właśnie
poprzez takie dokładne szukanie czy faktycznie taki element się znajduje
dokładnie z taką nazwą czy nie zależy nam na tym aż tak
bardzo i wybieramy tylko wersję z wybieramy
tylko wersję z regex'em który nam łapie niezależnie od wielkości liter
co tam mamy w naszym placeholderze ale tak właśnie działają te queries
zachęcam cię do przeczytania sobie ich wszystkich ponieważ w ten
sposób łatwiej zrozumiesz jak będziemy testować kolejne elementy naszej
aplikacji jak również zachęcam cię do tego żeby przelecieć sobie przez te metody
przez te mathcery które mamy tutaj w jest domie to też się bardzo przyda do tego żeby zrozumieć
jak będziemy testować i możliwe że zapytasz dobra ale ja nie chcę w żadnych
tutaj queries które wymyślił nam twórca tej biblioteki
ja chcę po prostu łapać moje elementy po klasie czy mogę to robić tak
aby ta biblioteka trochę nam to utrudnia właśnie z tego względu że
uznano że to jest zła praktyka i nie zachęca się do tego żeby tak to rozwiązywać
natomiast jeśli tutaj z tej funkcji render wyciągniemy sobie container tak
to się nazywa to możemy podobnie jak w poprzedniej lekcji stworzyć sobie przykład
który nazwiemy input wykorzystamy
container query selector i na przykład damy tutaj
my input jeśli
stworzymy sobie teraz klasę my
input i
sprawdzimy czy mój input który łapiemy sobie po nazwie klasy
jest w komponencie to dostaniemy też przechodzący
test ale tak jak mówiłem nie zachęcam do tego i to na tyle w tej lekcji
napisaliśmy pierwszy prosty test który przechodzi