Сейчас в дизайн комьюнити только и разговоров, что о токенах. На любой айтишечной конференции, в докладах дизайн блока, одна - две лекции 100% будет о токенах. В основном, светлые умы русского UX будут вам рассказывать, как они ловко сконектились с разработкой или больше не используют стили(на самом деле используют) считают их прошлым веком.

Но вот о чем они не рассказывают, это как модные и хайповые local variables в их дизайн системах, мешают развитию продукта и масштабированию в коде.

Да, мы знаем что самая базовая связь атомарного подхода с разработкой идет как раз, через дизайн токены. Дизайнеры создают базовые значения для цветов/размеров/отступов/обводок и тд. Затем применяют это значение к соответствующему элементу в компоненте, тут то и кроется основная проблема. То, что задумывалось как ускорение разработки и легкость масштабирования, в перспективе мешает развитию дизайн-системы, базовые значения множатся, создаются значения исключительно для каждого отдельного компонента, по сути превращаясь в семантику, завязываясь на базовых значениях, система теряет гибкость и возможность дальнейшего масштабирования. В результате команды начинают страшно костылить, разламывая компоненты или лупить неподходящие к элементам токены. Сейчас много гигантов на эти грабли наступают, потому что ни один отдел дизайн системы или консистентности(привет ozon design) никогда эти костыли не апрувнут и не пропустят

Как мы в Protocol Design System решили эту проблему? Да очень просто(очень сложно) - углубились на два уровня вниз. От базовых значений мы создали семантические значения(alias) значения, но это ни для кого не секрет, все надеюсь про них знают. Это токены которые наследуют базовые значения и ТОЛЬКО ОНИ используются в проекте, базовые значения мы создали и забыли про них и больше не меняли. Так поступили с цветовой палитрой, создав растяжку из 10 цветов и для каждого из них завели соотвествующий семантический токен, например --pui-color-bg-accent этот токен используется только для фона какой либо поверхности. А только следом уже создаются локальные токены для каждого компонента, то есть, сам компонент уже становится группой токенов, и создается так называемые компонентные токены(components). Финальный токен такого формата выглядит как button-color-default-bg-pui-color-bg-surface-brand-secondary- hovered. Очень и очень сложно, по предыдущему посту вы уже знаете, что мы в команде любим усложнять себе жизнь прямо со старта, а не оставлять страдания на потом.

Так вот, мы выяснили что компонентные токены - уникальные для каждого компонента. Применяются только на него и полностью описывают его внешний вид в любом состоянии. Таким образом мы можем точечно влиять на каждый компонент, не меняя базовые значения и не влияя на всю систему целиком, точно так же это у нас реализовано и со стороны кода, что позволяет легко масштабироваться и сохранять такую ценную для нас гибкость имея совершенно разные продукты. Подчеркну, если ваша дизайн-система существует в рамках одного продукта или даже одной экосистемы, то подобная вложенность может быть излишней. Но если вы занимаетесь проектированием в большой компании, то подобный подход может сильно облегчить вам жизнь и избежать десятка рефакторингов