Architektura komponentów w React - tworzenie bibliotek i aplikacji

Warsztat ekspercki to coś więcej niż szkolenie. To praca w kontekście konkretnych problemów.

Kod: react-libs
Kategoria: React
Forma: 10% wykłady, 90% warsztaty
Czas trwania: 3 dni
Odbiorcy: developerzy, architekci
Zapisy: Indywidualne zamówienie i dopasowanie dla grupy.
Logistyka: W siedzibie klienta lub w innym dowolnym miejscu.

Jesteś matką smoka.

Kiedyś był to przyjazny towarzysz, ale teraz stał się monstrum o wielu głowach. Okoliczności zmuszają cię do karmienia potwora, który daje ci władzę. Z czasem wyrastają mu kolejne głowy i nogi, a gardziel zrasta się z płucami. Musisz złamać mu skrzydła, które nienaturalnie przybrały na wielkości uniemożliwiając mu wydostanie się z jamy na nocne łowy. Ten smok, kiedy chce upiec jednego barana, musi spalić całą wioskę. Każda jego głowa chce iść w inną stronę, głowy te zaczynają się kąsać. Nienawidzisz tego potwora, który niegdyś był małym i uroczym pisklęciem, a teraz stanowi dla wszystkich zagrożenie i budzi obrzydzenie. Chcesz go zabić, wskazując na błąd natury, ale gdzieś w głębi serca zastanawiasz się, dlaczego ten nowy smok, który niebawem wykluje się z jajka, miałby być inny, lepszy.

Na szczęście możemy odłożyć na bok skojarzenia z serialowymi dylematami, bo przecież na frontendzie nie hodujemy smoków, tylko kod. Kod, początkowo pieszczony i zaopiekowany, też może stać się potworem. Niemniej “zabicie” kodu i napisanie go od początku zazwyczaj prowadzi do tych samych rezultatów. Wiesz, że modularyzacja jest dobra. Dzielisz i rządzisz. Wyodrębniasz odrębne moduły, definiujesz nowe komponenty. Ale i tak na końcu czujesz, że coś jest nie tak, bo wszystko jest ze sobą splątane. Połamane, niepotrzebne funkcje, które zostały kiedyś na wyrost wrzucone do jednego komponentu zwisają tak bezwładnie i boisz się je oderwać. Implementacje kolejnych wymagań chcą iść w różne strony, kąsają się. Co prawda są wydzielone do różnych komponentów, ale nadal są złączone na sztywno szyją, bo każda z nich musi być połączona z tułowiem, w którym bije potrzebne głowie serce, a które też nie może bić bez mózgu.

A gdzie jest mózg?

Ostatnie pytanie niech będzie pytaniem retorycznym, które zachęci do udziału w warsztatach, na których pokażemy, że smoki istnieją tylko w bajkach, a świat może być dużo prostszy.

Każdy, kto programuje interfejs użytkownika, rozumie potrzebę wyodrębniania komponentów. Mało kto jednak ma pomysł i pewność, jak te komponenty zdefiniować i ułożyć, aby one ze sobą dobrze współgrały. Są to swego rodzaju warsztaty z kompozycji, gdzie nauczymy się jak określać granice odpowiedzialności komponentów, by te mogły robić dokładnie jedną rzecz “raz a dobrze” i jak wygodnie je komponować w konkretnym kontekście. Nauczymy się, jak stawiać czoła intuicji, która przedkłada wizualną strukturę interfejsu użytkownika nad logikę odpowiedzialności jednostek.

Na warsztatach poznamy, jak tworzyć komponentowy kod biblioteczny, który skaluje się wraz z rosnącą liczbą użyć czy nowych (często między sobą sprzecznych) wymagań. Dzięki poznanemu podejściu do tworzenia komponentów zredukujesz diametralnie poziom złożoności kodu, twoje moduły będą małe i nieskomplikowane. Nauczysz się składać je w większe części tak tylko jak ci się spodoba. Będzie to satysfakcjonujące doświadczenie, w którym raz napisany komponent nie będzie ograniczał ciebie przy dalszej rozbudowie biblioteki czy aplikacji jej używającej.

WARSZTATY SĄ DLA CIEBIE, JEŚLI:

  • wiesz czym są komponenty, hooki, propsy, kontekst, ale nie wiesz co dalej z tym zrobić
  • zastanawiasz się, czym różni się komponent od zwykłej funkcji
  • uważasz, że kontekst służy tylko do trzymania globalnych danych
  • myślisz, że kontekst to tylko alternatywa dla reduxa
  • używasz tzw. children inspection, ale nałożyłeś mnóstwo ograniczeń na komponent
  • pomimo wszelkich starań twoje komponenty są pełne pętli i rozgałęzień
  • chciałbyś pisać bardziej przewidywalny kod - odporny na zmiany wymagań oraz łatwo wnioskowany
  • tworzysz bibliotekę UI, na przykład design system
  • pracujesz nad systemem komponentów i chciałbyś je jakoś rozwikłać
  • chcesz zagłębić się w architekturę compound components
  • nawet nie tworzysz biblioteki, ale cenisz sobie dobrą architekturę

PO WARSZTATACH

  • nauczysz się kilku heurystyk pomagających w tworzeniu komponentów low-coupling
  • będziesz pisał kod mniej podatny na błędy
  • zmienisz swoje myślenie o tym, czym jest komponent
  • twoje projekty będą czytelniejsze dzięki lepszemu użyciu JSX
  • nauczysz się rozwiązywać duże problemy bez tworzenia przerośniętych komponentów
  • będziesz tworzył komponenty, które się “fajnie razem korzysta”
  • dowiesz się, jak nie ograniczać end-usera w stosowaniu tzw. “idiomatic react”

Wyróżniki warsztatu

  • Zajęcia praktyczne, praca na własnym kodzie, etapami - commit po commicie
  • warsztaty przeznaczone dla osób, które są biegłe w tworzeniu aplikacji reactowych i interesują je zagadnienia z reużywalności kodu oraz tworzenia bibliotek ogólnego przeznaczenia (np. design system)
  • mocno skupiamy się na API komponentów (piszemy w Typescript)
  • pozbywamy się zbędnych abstrakcji i logiki niebiznesowej
  • wyrabiamy wyczucie: co powinno być “wewnątrz” a co “poza” danym komponentem
  • czysty React: tylko JSX, propsy, hooki i kontekst

Program Warsztatu eksperckiego

Program jest ramą w jakiej możemy się poruszać merytorycznie - program dla konkretnego szkolenia dedykowanego ustalamy z grupą na podstawie analizy przed-szkoleniowej.

  1. Doświadczenie: projekt i implementacja prostego komponentu listy
    1. użycie intuicji do zbudowania komponentu bibliotecznego
    2. symulacja serii pojawiających się nowych wymagań funkcjonalnych
    3. iteracyjne rozbudowywanie komponentu podczas symulacji
    4. obserwacja rozrostu i splątania komponentów
  2. Stopnie swobody komponentów
    1. high-coupling, no-coupling, low-coupling
    2. mindset konfiguracji i mindset kompozycji
    3. korzyści i konsekwencje przerzucania odpowiedzialności
  3. Compound components - sposób na rozplątanie odpowiedzialności komponentów
    1. komponenty niekomunikujące się
    2. komunikacja pasywna
      1. powtórzenie doświadczenia implementacji listy
      2. props inspection
      3. ograniczenia virtual DOM jako źródła informacji
    3. komunikacja aktywna
      1. powtórzenie doświadczenia implementacji listy
      2. React context
      3. Single source of truth w DOM - czy to możliwe?
      4. Compound events
    4. porównanie poziomu skomplikowania kodu różnych podejść
  4. Heurystyki rozplątywania komponentów
    1. separacja logiki i renderingu
    2. wielowarstwowa kompozycja
    3. parent vs owner
    4. przetwarzanie tablic
    5. ReactNode vs string
    6. zakres w callbackach
  5. Ćwiczenie - refactoring przykładu z życia wziętego.
    1. użycie przedstawionych heurystyk do przebudowania realnego komponentu typu Breadcrumbs
    2. porównanie poziomu skomplikowania kodu przed i po refactoringu
    3. burza mózgów - nowe wymagania i analiza konieczności modyfikacji kodu bibliotecznego


Pobierz program w formacie PDF

Trenerzy

Poznaj ekspertów, którzy mogą poprowadzić Twój Warsztat.

Materiały związane z warsztatem

Idea renesansowej pracowni - Bottegi zakłada nieustanną pracę jej członków i dzielenie się jej wynikami.

  • Looking for the Holy Grail of Mobile Web Performance
    KATEGORIE: Front-end

    W świecie mobilnym Istnieje przeświadczenie, że jedynie aplikacje natywne są w stanie sprostać oczekiwaniom użytkowników. Wraz z pojawieniem się Progresywnych Aplikacji Webowych, które mają przenieść na platformę webową wiele cech zarezerwowanych dotąd tylko dla rozwiązań natywnych, oczekiwania dotyczące wydajności są silniejsze niż kiedykolwiek wcześniej. Czy Web jest w stanie im sprostać?

    Autor Bottega:

    Adam Bar

    Powiązane szkolenia dedykowane:

    (zobacz wszystkie powiązane...)

    Web Performance Optimization

    Svelte: Reaktywne Aplikacje Frontendowe

    Powiązane usługi:

    Audyty architektury

    Audyty architektury

  • JSON taki albo owaki... czyli kontrolowanie struktur z JSON Schema
    KATEGORIE: Front-end

    Slides

    JSON jest najpopularniejszym formatem definiowania/wymiany danych w sieci. Jest elastyczny niczym XML oraz zwięzły, jak to tylko możliwe. Nie mniej, rozwiązłość strukturalna JSONów powoduje utratę kontroli nad tym, jakie dane są przechowywane. Jeśli chcesz kontrolować, co może być przechowywane w formacie JSON, zerknijmy na JSON Schema.

    Autor Bottega:

    Tomasz Ducin

    Powiązane szkolenia dedykowane:

    (zobacz wszystkie powiązane...)

    Web Performance Optimization

    Svelte: Reaktywne Aplikacje Frontendowe

    Powiązane usługi:

    Audyty architektury

    Audyty architektury

  • A Ty co zrobisz bez frameworka
    KATEGORIE: Front-end

    Podczas tej prezentacji poznamy lit-html – bibliotekę, która w prosty sposób abstrahuje zawiłości operacji na DOM-ie – oraz jej kuzyna lit-element, dzięki któremu Web Componenty są dziś na wyciągnięcie ręki. Sprawdzimy, jak wiele można mieć za tak niewiele i zastanowimy się, czy lit-html może stanowić alternatywę dla frameworków.

    Autor Bottega:

    Adam Bar

    Powiązane szkolenia dedykowane:

    (zobacz wszystkie powiązane...)

    Web Performance Optimization

    Svelte: Reaktywne Aplikacje Frontendowe

    Powiązane usługi:

    Audyty architektury

    Audyty architektury

Zamów warsztat

Imię i nazwisko:
Firma:
E-mail:
Nr tel:
Temat:
Wiadomość:

Jeżeli preferujesz osobisty kontakt to zawsze możesz zadzwonić.

Iwona Sobótka

Koordynatorka szkoleń


Twoje dane osobowe przetwarzamy, aby udzielić odpowiedzi na Twoje pytanie. Administratorem Twoich danych osobowych jest Bottega It Minds Sławomir Sobótka. Przysługuje Ci prawo wniesienia sprzeciwu wobec przetwarzania, prawo dostępu do danych, prawo żądania ich sprostowania, usunięcia lub ograniczenia ich przetwarzania. Szczegółowe informacje dotyczące przetwarzania Twoich danych osobowych znajdują się TUTAJ.