Architektura komponentów w React - tworzenie bibliotek i aplikacji

Warsztaty są wynikiem mojej kilkuletniej pracy połączonej z badaniami nad innymi bibliotekami o podobnym charakterze, mających te same wyzwania technologiczne. Nadszedł czas, aby podzielić się sprawdzonymi na produkcji rozwiązaniami architektonicznymi, które uważam za niesłychanie proste (ale nie łatwe!) w zastosowaniu w każdej bibliotece komponentowej. Podczas warsztatów wykorzystamy w praktyce cztery różne podejścia do tworzenia komponentu bibliotecznego, poznamy ograniczenia i możliwości każdego z nich zarówno z perspektywy maintainera i konsumenta biblioteki.

Na koniec omówimy kilka przydatnych wskazówek, które pozwolą rozplątać zależności między komponentami czyniąc je łatwiejsze w użyciu, prostsze w implementacji i bardziej elastycznymi.

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”