Rozpoczynając nowy projekt w Angularze lub w innym frameworku, niewielu deweloperów poświęca odpowiednią uwagę strategii komponentów UI. Standardowe podejście jest proste: zaimportuj Angular Material lub inną popularną bibliotekę i przejdź do „ważniejszych” zadań. To szybkie, łatwe i działa – do czasu.
Fałszywa ekonomia bibliotek komponentów
Wielokrotnie obserwowałem ten schemat w swojej karierze. Projekt rozpoczyna się „na szybko” z gotowymi komponentami obsługującymi wszystko, od przycisków po złożone kontrolki autouzupełniania. Zespół cieszy się z szybkiego tempa, a biznes jest pod wrażeniem błyskawicznych postępów. Potem, nieuchronnie, pojawiają się niestandardowe wymagania.
Weźmy pod uwagę ten powszechny scenariusz: „Musimy zmodyfikować Autocomplete tak, aby gdy użytkownik wpisze trzy litery, dokładnie te litery pojawiały się pogrubione na liście sugestii.” Wydaje się proste, prawda? Nie w przypadku komponentów zewnętrznych.
To, co następuje, to desperacka „rzeźba” coraz bardziej problematycznych obejść. Deweloperzy uciekają się do ustawiania ViewEncapsulation na None (uznany anty-wzorzec), nadpisywania stylów (najlepiej z setkami linii CSS), które nigdy nie miały być nadpisywane, i ogólnie rzeźbienia w wewnętrznej strukturze komponentu (i najlepiej odpalić jeszcze funkcję internalUpdate() wewnętrzne z komponentu)
Bomba zegarowa długu technicznego
Brałem udział w projekcie przepełnionym takimi „rzeźbiarskimi” modyfikacjami. Baza kodu była nafaszerowana obejściami i nadpisaniami stylów dla komponentów Angular Material. Wydajność cierpiała, ale funkcjonalnie wszystko działało – dopóki zespół nie musiał zaktualizować Angulara z wersji 12 do 15.
Angular Material 15 wprowadził liczne „breaking changes”, co jest zrozumiałe z perspektywy twórców biblioteki. Aktualizacja zepsuła praktycznie wszystko. Wszystkie „hacki” nie trafiały już w odpowiednie elementy. Pozycjonowanie list rozwijanych się zmieniło. Kontrolki formularzy zachowywały się inaczej.
W obliczu napiętego terminu zespół zrobił to, co wydawało się konieczne: dodał nowe warstwy „rzeźby” na wierzch starych. Rezultat? Ledwo utrzymywalna warstwa UI, gdzie nawet drobne zmiany groziły zawaleniem całej konstrukcji.
Podejście shadcn: Lepsza alternatywa
To nie jest krytyka Angular Material – to doskonała biblioteka. Problem leży w tym, jak podchodzimy do bibliotek komponentów w długoterminowych projektach komercyjnych.
Biblioteki takie jak shadcn oferują przekonującą alternatywę. Zamiast importować komponenty-czarne skrzynki, otrzymujesz kod źródłowy, który możesz w pełni posiadać i dostosowywać. Tak, takie podejście wymaga większej początkowej inwestycji, gdy adaptujesz i rozszerzasz te komponenty do swoich potrzeb. Jednak zyskujesz pełną kontrolę i niezależność.
Dzięki temu podejściu:
- Niestandardowe wymagania stają się prostymi implementacjami, a nie karkołomnymi obejściami
- Twoje komponenty ewoluują razem z aplikacją, zamiast z nią walczyć
- Aktualizacje frameworka pozostają zarządzalne, ponieważ kontrolujesz proces aktualizacji
- Unikasz kaskady długu technicznego, który wynika z obchodzenia zamierzonego sposobu użycia bibliotek komponentów
Dokonywanie właściwego wyboru dla projektów komercyjnych
W przypadku krótkoterminowych projektów lub MVP, gdzie czas wprowadzenia na rynek jest najważniejszy, gotowe biblioteki komponentów mają sens. Ale dla aplikacji komercyjnych, które mają ewoluować przez wiele lat, warto rozważyć całkowity koszt posiadania.
Czas, który oszczędzasz na początku, korzystając z komponentów zewnętrznych, często jest spłacany z nawiązką, gdy pojawiają się niestandardowe wymagania – a zawsze się pojawiają. Przejmując kontrolę nad biblioteką komponentów od początku, dokonujesz strategicznej inwestycji w utrzymywalność i długowieczność swojego projektu.
Gdy następnym razem rozpoczniesz projekt Angular, oprzyj się pokusie prostego zaimportowania biblioteki komponentów i przejścia dalej. Zadaj sobie pytanie: Jak unikalne staną się nasze wymagania UI? Jak długo będzie żyła ta aplikacja? I co najważniejsze, kto powinien kontrolować los naszych komponentów UI – my, czy zewnętrzna biblioteka, której priorytety mogą nie pokrywać się z naszymi?
Wybierz mądrze.