Kontrolki Web UI: Zrób własne lub zapłać później

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, że 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 wtedy zazwyczaj się dzieje, to desperacka „rzeźba” wokół zaimportowanego kodu biblioteki.

Często widzę wtedy takie rzeczy w Angularze jak:

• ViewEncapsulation: None (uznany anty-wzorzec),
• Nadpisywanie stylów (najlepiej z setkami linii CSS),
• Włączanie wewnętrznych funkcji kontrolki, takich jak np. internalUpdate()

Wpływ na wydajność

Biblioteki komponentów często zawierają kod, którego nigdy nie wykorzystasz – dead code, który mimo to trafia do bundle’a produkcyjnego. Angular Material waży kilka megabajtów, nawet jeśli używasz tylko trzech komponentów. Sytuacja staje się jeszcze gorsza, gdy tworzysz własne nakładki na zewnętrzne komponenty. W bundle’u ląduje wtedy podwójny kod: oryginalny komponent (często w pełnej wersji, choć nie jest wyświetlany), plus Twoja warstwa abstrakcji z własnymi stylami i logiką. Własne komponenty pozwalają na precyzyjne kontrolowanie rozmiaru aplikacji i włączenie tylko tego kodu, który rzeczywiście jest potrzebny.

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.

Temat ten często przewija się w internecie i każdy kto brał udział w większym projekcie dochodzi do tego samego wniosku.

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

Ten artykuł 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?