HTML w systemach projektowych

System projektowy to wspólna biblioteka komponentów, tokenów, wzorców i wytycznych używana w produktach danej organizacji. Część systemu dotycząca HTML obejmuje konwencje znaczników, dzięki czemu każdy produkt renderuje spójne struktury przycisków, modali, formularzy i kart.

Tokeny to atomowe wartości projektowe (color: blue-500, spacing: 16px). Komponenty to wielokrotnego użytku jednostki HTML+CSS+JS (Button, Modal, TextField). Wzorce to kompozycje wyższego poziomu (formularz logowania, karta treści z awatarem). Struktura HTML jest ustalana na poziomie komponentu, a wzorce łączą komponenty.

Komponenty kodują dobre praktyki: każdy Button korzysta z elementu <button> (a nie div) i ma prawidłowy atrybut type. Każdy Modal przechwytuje fokus, obsługuje klawisz Escape i ma właściwe role ARIA. Stosowanie komponentów eliminuje konieczność ponownego implementowania dostępności dla każdej funkcji produktu.

Storybook renderuje każdy komponent w izolacji, z różnymi propsami i wariantami. Projektanci i osoby zarządzające produktem widzą dostępne komponenty bez czytania kodu, a programiści widzą przykłady użycia bez przeszukiwania kodu źródłowego. Jest de facto standardem dokumentowania systemów projektowych.

System projektowy należy traktować jak pakiet publikowany z użyciem semver. Przełomowe zmiany HTML/CSS (na przykład zmiana nazwy klasy CSS, od której zależą konsumenci, lub usunięcie slotu komponentu) wymagają zwiększenia głównego numeru wersji. Konsumenci aktualizują pakiet świadomie i zgodnie ze swoim harmonogramem, a nie niespodziewanie.

Propsy, sloty i udostępniane części komponentu są publicznym API. Po udostępnieniu ich konsumentom należy traktować je jako kosztowne w zmianie. Wycofywanie powinno przebiegać stopniowo: nowe API należy dodać obok starego, rejestrować ostrzeżenia o użyciu starego i usuwać je dopiero po upływie odpowiednio zmierzonego okresu.

Tokeny umożliwiają tworzenie motywów: wystarczy zamienić mapę tokenów kolorów, aby każdy komponent przejął nową paletę. White-labeling, czyli współdzielenie komponentów przez różne marki przy zachowaniu odmiennych warstw wizualnych, staje się prosty, gdy wszystkim sterują tokeny, a komponenty odwołują się do tokenów zamiast do wartości wpisanych na stałe.

W organizacjach korzystających z wielu frameworków (React, Vue, Angular) komponenty webowe zapewniają jedną implementację działającą wszędzie. Można je tworzyć za pomocą Lit, FAST lub vanilla i korzystać z nich w taki sam sposób w dowolnym frameworku. Kontraktem jest struktura HTML, a nie framework.

Systemy projektowe jednorazowo wbudowują dostępność w każdy komponent: obsługę klawiatury, role ARIA, zarządzanie fokusem i kontrast kolorów. Zespoły produktowe korzystające z systemu otrzymują dostępność bez konieczności budowania jej od podstaw dla każdej funkcji, co mierzalnie zmniejsza liczbę błędów związanych z dostępnością w całej firmie.

Należy śledzić, które produkty korzystają z której wersji systemu projektowego. Narzędzia takie jak katalog komponentów Backstage, własne boty Slack monitorujące package.json czy proste wewnętrzne pulpity pokazują, w których miejscach nie wdrożono jeszcze najnowszej wersji. Wskaźniki wdrożenia uzasadniają dalsze inwestycje.

Należy ustalić, kto może dodawać komponenty: wyłącznie centralny zespół systemu projektowego czy także zespoły produktowe? Każdy model ma swoje kompromisy. Zespoły centralne wdrażają zmiany wolniej, ale utrzymują jakość; zespoły produktowe działają szybciej, lecz zwiększają ryzyko fragmentacji. Wybór powinien wynikać ze skali organizacji i być dokonany świadomie.

Systemy projektowe to produkty, które stale się rozwijają. Komponenty należy dodawać, gdy w produktach pojawiają się nowe wzorce, wycofywać te, które przestają pasować, oraz refaktoryzować system, gdy trzeba zmienić fundamentalne decyzje. System należy traktować jak oprogramowanie z planem rozwoju, a nie jak ukończony artefakt.

Dlaczego tokeny projektowe (takie jak color: blue-500 i spacing: 16px) są preferowane zamiast wartości wpisanych na stałe w komponentach?

Systemy projektowe łączą tokeny (wartości atomowe), komponenty (wielokrotnego użytku jednostki HTML) i wzorce (kompozycje wyższego poziomu) w wersjonowaną bibliotekę współdzieloną przez wiele produktów. Do dokumentacji należy używać Storybook, do korzystania z komponentów w różnych frameworkach — komponentów webowych, a do zapewnienia stabilności — semver. Dostępność należy wbudować w każdy komponent, śledzić wdrożenia i rozwijać system jako produkt, który stale się zmienia.