Proč si dělám komponentovou stránku ke každému projektu

U každého většího projektu si kromě appky samotné postavím ještě jednu stránku navíc, kterou nikdy neuvidí klient ani uživatel — komponentovou/typografickou stránku. Je to jedna route, typicky /styleguide nebo /dev/components, vyřazená z indexace, kde je natvrdo vyrenderovaná celá typografická škála, všechny varianty tlačítek, karet, badge a barevná paleta.

Důvod je jednoduchý: jakmile má projekt víc než pár stránek, začnou se do kódu vkrádat drobné odchylky — jinde použitý odstín šedé pro „utlumený“ text, jinde trochu jiný border-radius na kartě, jinde jiná mezera mezi ikonou a textem. Každá odchylka zvlášť je nepostřehnutelná, ale dohromady dělají appku vizuálně nesourodou.

Komponentová stránka funguje jako lakmusový papírek. Renderuje stejné proměnné a stejné Tailwind třídy, jaké používá produkční kód — nejsou to ukázkové hodnoty napsané zvlášť, ale přímo ty samé tokeny. Když tam přidám novou variantu tlačítka nebo změním hodnotu border-radius, hned vidím vedle sebe všechno, co by to mohlo ovlivnit, a to dřív, než to omylem rozhodí něco jinde na appce.

Na tomhle webu jsme si toho v posledních dnech užili dost — karta u referencí, avatar, mezery mezi textem — než jsme se trefili do finálního vzhledu, prošlo to několika iteracemi. Kdybych měl od začátku jednu stránku, kde vidím kartu vedle sebe se všemi ostatními kartami na webu, spoustu těch kol bych si ušetřil.

U větších systémů jako Cleenly nebo Syntha, kde běží stovky komponent napříč desítkami obrazovek, to platí dvojnásob. Bez jednoho místa, kde vidíte všechno hierarchicky vedle sebe — od základních prvků přes složené komponenty až po celé sekce — se prakticky nedá ručně ověřit, že každá z nich pořád odpovídá aktuálním UI a UX standardům. Komponentová stránka tak funguje i jako checklist: projdete ji před každým větším releasem a hned vidíte, co zaostává.