Designové tokeny: CTI-architektura, pojmenování, příklady pro vývojáře

Efektivní správa stylů: Architektura a pojmenování designových tokenů s metodologií CTI

Designové tokeny jsou základním prvkem moderních design systémů, které zajišťují bezproblémovou spolupráci mezi designéry a vývojáři. Umožňují standardizovat vizuální atributy produktu, jako jsou barvy, písma a mezery, a převádějí surové hodnoty na pojmenované proměnné. Správně navržený systém tokenů výrazně urychluje vývoj nových rozhraní, zjednodušuje škálování a přizpůsobení a minimalizuje technický dluh tím, že eliminuje potřebu ručně měnit napevno zakódované styly v roztříštěných komponentách. V tomto materiálu se podrobně podíváme na architekturu designových tokenů a specifika pojmenování podle populární metodologie CTI, která tvoří základ mnoha pokročilých design systémů.

Víceúrovňová abstrakce designových tokenů

Pro vytvoření flexibilního a škálovatelného design systému je kriticky důležitý přístup k abstrakci hodnot. Moderní systémy používají třívrstvý model (Primitiv → Sémantika → Komponenta), ke kterému se pro úplnost často přidává nulová vrstva – surová data. Tento model zajišťuje strukturovaný tok dat, kde se změny na nižších úrovních automaticky šíří na vyšší, což zaručuje konzistenci a zjednodušuje globální aktualizace stylů.

0. Surové hodnoty (Raw Values): Jedná se o základní, neabstrahovaná data, jako jsou hexadecimální kódy barev (#0055FF), pixelové hodnoty velikostí (16px) nebo konkrétní názvy písem ('Inter', sans-serif). Jsou výchozím bodem, ale neměly by být přímo používány v kódu nebo maketách, aby se předešlo technickému dluhu.

1. Primitivní tokeny (Primitive Tokens): Toto je první úroveň abstrakce. Primitivní tokeny digitalizují surová data a dávají jim smysluplná, ale stále abstraktní jména. Například #0055FF se může stát blue-500. Pokud se značka rozhodne změnit odstín své firemní modré, stačí aktualizovat hodnotu blue-500 na jednom místě a tato změna se automaticky aplikuje na všechny závislé tokeny. Primitivní tokeny často popisují barevné palety, škály mezer nebo velikosti písem.

2. Sémantické tokeny (Semantic Tokens): Tyto tokeny popisují roli nebo účel zdroje v rozhraní a odpovídají na otázku „Proč?“. Propojují primitivní tokeny s konkrétními kontexty použití. Například blue-500 může být použit pro vytvoření color-bg-primary (primární barva pozadí). Sémantické tokeny hrají klíčovou roli při implementaci témat (světlé/tmavé) a adaptaci na různé režimy, protože tentýž sémantický token může odkazovat na různé primitivy v závislosti na aktivním tématu.

3. Komponentní tokeny (Component Tokens): Tato úroveň popisuje konkrétní místo aplikace stylu uvnitř samostatného prvku nebo komponenty a odpovídá na otázku „Kde?“. Komponentní tokeny umožňují přesné nastavení stylů pro konkrétní komponenty, aniž by ovlivnily jiné prvky, které mohou používat stejné sémantické tokeny. Slouží k řízení výjimek a specifických požadavků komponent, přičemž zajišťují dědičnost obecné sémantiky. Například color-button-bg-primary-hover může být unikátní pro tlačítko, i když jeho základní sémantický token je použit jinde.

Metodologie CTI: Architektura pojmenování

CTI (Category → Type → Item) je jedním z nejpopulárnějších modelů pojmenování designových tokenů, obzvláště široce používaným ve spojení s nástrojem Style Dictionary, který tento přístup popularizoval. Hlavní myšlenka CTI spočívá v tom, že na prvním místě v názvu tokenu je jeho fyzická vlastnost nebo kategorie, nikoli komponenta, ke které se vztahuje. Díky tomu je systém snadno interpretovatelný pro kompilátory a skripty.

Formule pojmenování v CTI obvykle vypadá takto: Category-Type-Item-Subitem-State.

Rozeberme si každý prvek:

• Category (Kategorie): Definuje základní fyzickou povahu tokenu. Je to vždy první slovo v názvu tokenu a označuje typ dat. Příklady: color (barva), size (velikost), font (písmo), spacing (mezera), radius (zaoblení).
• Type (Typ): Popisuje, na jakou vlastnost uživatelského rozhraní se daná kategorie vztahuje. Příklady: background (pozadí), text (text), border (rámeček), icon (ikona).
• Item (Položka): Označuje konkrétní prvek nebo komponentu rozhraní, ke které se token vztahuje. Příklady: button (tlačítko), dropdown (rozbalovací seznam), container (kontejner).
• Sub-item (Podpoložka / Modifikátor): Přidává upřesnění k prvku, označující jeho variantu nebo roli. Příklady: primary, secondary, success, warning, danger.
• State (Stav): Popisuje interaktivní stav prvku. Příklady: hover (při najetí myší), active (aktivní), disabled (deaktivované), focus (ve fokusu).

Například token pro barvu pozadí primárního tlačítka v aktivním stavu bude vypadat takto: color-background-button-primary-active.

Výhody a nevýhody přístupu CTI

Jako každá metodologie má i CTI své silné a slabé stránky, které je důležité zohlednit při návrhu design systému.

Výhody CTI:

• Optimalizace pro kompilátory: Jelikož první slovo tokenu vždy označuje jeho kategorii (color, size, font), je pro kompilační skripty (například Style Dictionary) mimořádně snadné pochopit, s jakými daty pracují. To zjednodušuje automatické generování CSS proměnných, SCSS mixinů, Swift souborů a dalších formátů z JSON definic tokenů, čímž se minimalizuje potřeba vlastních konfigurací.
• Efektivní audit a globální změny: Pro frontend vývojáře, který chce zkontrolovat nebo změnit všechny mezery v aplikaci, stačí provést vyhledávání podle prefixu $spacing- nebo --spacing-. To umožňuje rychle získat kompletní seznam všech proměnných mezer, což je užitečné pro globální audit nebo hromadné změny.
• Standardizace: CTI je výchozí architekturou pro nástroje jako Style Dictionary, což ji činí dobře zdokumentovanou a srozumitelnou pro mnoho vývojářů, kteří pracovali s design systémy.

Nevýhody CTI:

• Rozptýlení stylů komponenty: V moderních komponentově orientovaných frameworkách (React, Vue) je komponenta, například tlačítko, izolovanou entitou. V přístupu CTI jsou styly tohoto tlačítka rozprostřeny po celém design systému: barva může být v colors.json, mezery v spacings.json a zaoblení v radii.json. Pro sestavení nebo odstranění komponenty musí vývojář „běhat“ po různých souborech, což narušuje kontext a komplikuje práci.
• Složitost vyhledávání a automatického doplňování: Pro vývojáře, který vytváří tlačítko, je často důležitější rychle najít vše, co se týká button a primary, než prefixy color nebo background. V dlouhých CTI tokenech se tato klíčová slova nacházejí uprostřed. Automatické doplňování v IDE nejprve nabízí mnoho barev a je třeba zadat většinu tokenu, aby se dostal k požadované komponentě.
• Pracnost refaktoringu komponent: Pokud se firma rozhodne přejmenovat komponentu (například modal na dialog), při přístupu CTI bude muset frontend vývojář hledat a přejmenovávat tokeny v mnoha různých kategoriích (barvy, stíny, z-index, mezery). Kdyby na prvním místě stála komponenta (dialog-bg-color), stačilo by přejmenovat jednu složku nebo skupinu tokenů.

Sémantické tokeny vs. Komponentní: Rozlišení rolí

Pochopení rozdílů mezi sémantickými a komponentními tokeny je klíčem k vybudování flexibilního design systému. Ačkoli jsou jejich formule pojmenování podobné, jejich účel se zásadně liší.

Sémantické tokeny odpovídají na otázku „Proč?“. Definují roli nebo záměr stylu. Například color-bg-primary znamená „primární barva pozadí“, bez ohledu na to, kde bude použita. Tyto tokeny jsou maximálně znovupoužitelné a slouží k zajištění celkové konzistence a podpory témat. Jejich formule pojmenování: [kategorie]-[vlastnost]-[role]-[intenzita]-[stav].

Komponentní tokeny odpovídají na otázku „Kde?“. Popisují styly specifické pro konkrétní komponentu. Používají se, když je třeba odchýlit se od obecné sémantiky nebo aplikovat unikátní styl na konkrétní prvek, aniž by to ovlivnilo jiné části systému. V podstatě se jedná o řízené výjimky. Jejich formule pojmenování: [kategorie]-[komponenta]-[vlastnost]-[role]-[intenzita]-[stav]. Jak je vidět, do řetězce se jednoduše přidá [komponenta].

Zlaté pravidlo: Pokud je token znovupoužitelný na různých místech a definuje obecný účel, jedná se o sémantický token. Pokud je třeba změnit styl pouze u jednoho konkrétního prvku nebo komponenty, jedná se o komponentní token.

Detailní rozbor prvků pojmenování CTI

Pro hlubší pochopení pojmenování CTI se podívejme podrobněji na každý z jeho prvků s příklady:

• Category (Kategorie): Hlavní složka nebo typ dat. Je to základ pro organizaci tokenů.

* color (barvy) – pro všechny barevné hodnoty.

* spacing (mezery) – pro vnitřní a vnější mezery.

* radius (zaoblení) – pro poloměry zaoblení rohů.

* shadow (stíny) – pro parametry stínů.

* typography (písma) – pro styly textu (velikost, váha, řádkování).

* size (velikost) – pro šířku/výšku prvků.

* z-index (vrstvy) – pro řízení pořadí překrývání prvků.

* opacity (průhlednost) – pro hodnoty průhlednosti.

* duration (animace) – pro dobu trvání animací.

• Property (Vlastnost): Upřesňuje, k jaké části UI se token v rámci kategorie vztahuje.

* bg / surface (pozadí) – pro barvu pozadí.

* text (text) – pro barvu textu.

* border (rámeček) – pro barvu rámečku.

* icon (ikona) – pro barvu ikon.

* outline / ring (fokus) – pro obrys při fokusu.

* overlay (překrytí pod modalem) – pro barvu překrytí.

• Role (Smysl / Účel): Definuje funkční nebo emocionální význam tokenu.

* primary / secondary / tertiary (důležitost) – pro označení hierarchie.

* brand / accent (firemní styl) – pro firemní barvy.

* success (úspěch/zelená) – pro zprávy o úspěchu.

* warning (upozornění/žlutá) – pro upozornění.

* danger / error (chyba/červená) – pro chyby.

* neutral (neutrální/šedá) – pro neutrální prvky.

* inverse (pro tmavá pozadí) – pro prvky, které invertují barvu na tmavém pozadí.

* static (nemění se v tématech: white/black) – pro barvy, které nezávisí na tématu.

• Prominence (Hierarchie / Intenzita): Popisuje intenzitu nebo viditelnost prvku.

* default / main / base – výchozí bod, základní stav (často se v názvu vynechává).

* muted (tlumený) – méně nápadný.

* subtle (sotva znatelný) – velmi jemný.

* intense (intenzivní) – výraznější.

* on-brand (kontrastní obsah na firemním pozadí) – pro text nebo ikony na firemním pozadí.

• State / Modifier / Size (Stav / Modifikátor / Velikost): Další upřesnění.

* Stavy: hover, active, focus, disabled – pro interaktivní stavy.

* Velikosti: sm, md, lg, xl – pro různé velikosti komponent nebo prvků.

Důležité pravidlo pro stav default: Pokud je token v základním, klidovém stavu, přípona -default se obvykle vynechává. Například color-text-primary ve výchozím nastavení implikuje default-stav. Jiné stavy se přidávají po roli, například color-text-primary-hover.

Praktické příklady struktury tokenů (CTI)

Pro upevnění pochopení se podívejme na několik praktických příkladů tvorby tokenů pro tlačítka, které demonstrují přechod od surových hodnot ke specifickým komponentním tokenům.

Příklad 1: Tlačítko accent ve stavu default

Předpokládejme, že máme primární tlačítko s akcentní barvou.

• 0. Raw Value: #0055FF (surová modrá barva)
• 1. Primitive Token: blue-500 (abstrakce surové hodnoty)
• 2. Semantic Token: color-bg-accent (primární akcentní barva pozadí, odkazuje na blue-500)
• 3. Component Token: color-button-accent-bg (barva pozadí akcentního tlačítka, odkazuje na color-bg-accent)

Zde vidíme, jak od obecného (blue-500) přecházíme ke specifičtějšímu (color-button-accent-bg). Důležité je, že v komponentním tokenu nepíšeme -default, protože se to předpokládá.

Příklad 2: Tlačítko accent ve stavu hover

Nyní se podívejme, jak se změní pojmenování pro stejné tlačítko při najetí myší.

• 0. Raw Value: #0044DD (tmavší modrá)
• 1. Primitive Token: blue-600 (abstrakce tmavší modré)
• 2. Semantic Token: color-bg-accent-hover (akcentní barva pozadí při najetí myší, odkazuje na blue-600)
• 3. Component Token: color-button-accent-bg-hover (barva pozadí akcentního tlačítka při najetí myší, odkazuje na color-bg-accent-hover)

Zde se explicitně přidává přípona -hover, která označuje interaktivní stav. Každá úroveň abstrakce činí design systém flexibilnějším, umožňuje měnit odstíny na úrovni primitivů, aniž by bylo nutné přejmenovávat tisíce tokenů.

Příklad 3: Tlačítko secondary ve stavu default

Pro sekundární tlačítko může být použita jiná paleta, například s průhledností.

• 0. Raw Value: #0055FF s průhledností 10% nebo rgba(0, 85, 255, 0.1)
• 1. Primitive Token: blue-transparent-100
• 2. Semantic Token: color-bg-secondary (odkazuje na blue-transparent-100)
• 3. Component Token: color-button-secondary-bg (odkazuje na color-bg-secondary)

Takový přístup umožňuje snadno přepínat palety pro různé typy tlačítek s využitím společné struktury tokenů.

Příklad 4: Text tlačítka secondary ve stavu default

Podívejme se na token pro text uvnitř sekundárního tlačítka.

• 0. Raw Value: #0055FF
• 1. Primitive Token: blue-500
• 2. Semantic Token: color-text-on-brand (barva textu na firemním pozadí, odkazuje na blue-500). Zde se objevuje modifikátor on-brand, který označuje kontext použití.
• 3. Component Token: color-button-secondary-text-on-brand (barva textu sekundárního tlačítka, odkazuje na color-text-on-brand)

Jak vidíte, vždy nejprve následuje kategorie (color, spacing, typography), poté vlastnost nebo komponenta, za nimiž následují modifikátory a stavy. Tento princip „od obecného ke konkrétnímu“ zajišťuje předvídatelnost a snadnou navigaci v design systému.

Co je důležité

• Designové tokeny jsou klíčovým prvkem pro vytváření škálovatelných, konzistentních a snadno udržovatelných design systémů, které předcházejí technickému dluhu spojenému s napevno zakódovanými styly.
• Víceúrovňový model abstrakce (Surové hodnoty → Primitivní → Sémantické → Komponentní tokeny) zajišťuje flexibilitu a ovladatelnost, což umožňuje provádět globální změny z jednoho místa.
• Metodologie CTI (Category → Type → Item) je populární přístup k pojmenování, který je vhodný pro automatické zpracování kompilátory, ale může komplikovat kontextové vyhledávání a refaktoring stylů komponent.
• Sémantické tokeny definují roli a účel stylu, zajišťují znovupoužitelnost a podporu témat, zatímco komponentní tokeny slouží k přesnému nastavení a řízení výjimek v rámci konkrétních komponent.
• Jasná pravidla pojmenování s využitím kategorií, vlastností, rolí, hierarchií a stavů jsou kriticky důležité pro udržení pořádku a předvídatelnosti v design systému.

— Editorial Team