Содержание · 9
Именование определяет живучесть системы. Разбираем схемы наименования, уровни абстракции и типичные ошибки, из-за которых токены становятся бесполезными.
Имя должно пережить значение
Главное правило именования: токен называется по роли, а не по внешнему виду. «color-blue» перестанет быть верным, как только акцент станет зелёным; «color-accent» переживёт любой ребрендинг.
То же с размерами: «space-16» лучше, чем «space-medium», потому что «средний» — понятие относительное, а 16 — точное.
Три уровня
Практика сошлась на трёхуровневой схеме. Каждый следующий уровень ссылается на предыдущий, а не задаёт значение напрямую.
Шкала отступов
Отступы должны браться из ограниченного набора, иначе в макетах появятся значения 13, 17 и 23 пикселя. Базовая единица 4 или 8 пикселей, шкала строится умножением.
Практичный набор: 4, 8, 12, 16, 24, 32, 48, 64, 96, 128. Десяти значений хватает почти на любой интерфейс.
- Одна базовая единица на всю систему.
- Не больше 10–12 значений в шкале.
- Именование по числу, а не по «small/medium/large».
- Отдельная шкала для внутренних отступов компонентов.
Цвет и темы
Поддержка тёмной темы решается на семантическом уровне: базовая палитра остаётся общей, а семантические токены получают разные значения в разных темах.
Именно поэтому важно не использовать базовые токены напрямую в компонентах: иначе тема не переключится.
Синхронизация с кодом
Токены имеют смысл только тогда, когда одинаково называются в макетах и в коде. Расхождение в именах убивает систему быстрее всего: дизайнер говорит «акцент», разработчик ищет «primary».
Решается общим источником: файл токенов, из которого генерируются и переменные для кода, и библиотека для редактора макетов.
Имя токена переживёт значение. «Цвет-опасности» живёт годами, «красный-500» умирает при первой смене палитры.
Версии и что делать с изменением
Токен живёт дольше макета, и рано или поздно его значение придётся менять. Разница между аккуратной системой и болезненной в том, что первая умеет объявлять изменение заранее. Работает это по правилам семантического версионирования: смена значения без смены имени — младшая версия, добавление токена — тоже, а переименование или удаление — старшая, потому что ломает то, что уже собрано.
Удалять токен сразу нельзя. Принятая практика — объявить его устаревшим: он продолжает работать, но помечен в описании и в редакторе, а рядом указан преемник. Срок жизни устаревшего токена задают явно — обычно один-два выпуска, — и до его конца проверяют, кто ещё им пользуется. Система, которая удаляет молча, приучает команды не обновляться, и через год половина продуктов сидит на старой версии.
- Изменение значения без переименования — самый дешёвый вид правки: обновляется всё сразу.
- Переименование обязательно сопровождается псевдонимом на переходный период.
- У каждого устаревшего токена есть преемник и дата, после которой он исчезнет.
- Список изменений ведётся человеческим языком: «фон карточки стал на тон светлее», а не «--c-12 → #F1F0EC».
- Массовое переименование делается один раз и скриптом, а не по мере встречи.
Чего токенами описывать не стоит
Соблазн описать токеном всё заканчивается системой, в которой полторы тысячи имён и никто не знает, какое взять. Токен оправдан там, где значение повторяется и может измениться централизованно: цвет, отступ, радиус, тень, шрифтовая пара, длительность анимации. Всё, что встречается один раз и никогда не переиспользуется, токеном быть не должно — это просто значение в компоненте.
Второй частый перебор — токенизация композиции. Ширина конкретного блока, положение конкретной иллюстрации, отступ, подобранный на глаз ради одного экрана, в систему не входят. Признак, по которому это видно: у токена не получается имя, объясняющее смысл, — приходится называть его по месту («--hero-left-gap»), и это честный сигнал остановиться.
Правила именования на практике
Общий принцип: имя описывает назначение, а значение остаётся сменным. Если при смене темы или палитры приходится переименовывать токены, система названа неверно.
- Плохо: «синий-600» — при смене фирменного цвета имя станет ложью.
- Хорошо: «поверхность-акцент» — описывает роль, а не цвет.
- Плохо: «отступ-16» — при смене шкалы придётся переименовывать всё.
- Хорошо: «отступ-м» — ступень шкалы, а не абсолютная величина.
- Плохо: «текст-серый» — не переживёт тёмную тему.
- Хорошо: «текст-второстепенный» — в тёмной теме меняется значение, не имя.
Что в итоге
Токены живут долго, если названы по роли, организованы в три уровня и одинаково называются в макетах и коде.
Ограничьте шкалу отступов десятью значениями и никогда не используйте базовые токены напрямую в компонентах.
Коротко
- Зачем нужны токены, если есть переменные?
- Токен — это переменная с назначением, а не со значением: не «серый 700», а «цвет второстепенного текста». Благодаря этому тему можно сменить целиком, не переписывая макеты и код.
- Сколько уровней токенов достаточно?
- Двух: базовый набор значений и смысловой слой поверх него. Третий уровень для отдельных компонентов заводят только тогда, когда без него действительно не обойтись, — иначе система становится непроходимой.
Состояния компонентов
Загрузка, ошибка, пустота, отключено, фокус с клавиатуры. Разбираем полный набор состояний и то, почему интерфейс разваливается именно на них.ДальшеЧитайте также
Посмотреть примеры
Нашли ошибку или неточность в атрибуции? Напишите нам
Обсуждение
Загружаем…