Вольный перевод What Are Design Tokens?

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

Design токены начинают набирать обороты в сообществе дизайнеров, но они не являются совершенно новой концепцией. Например, есть отличное выступление Jina Anne и Jon Levine в 2016 году, где они говорили как design токены используются в Lightning Design System на Salesforce. Они описывают сложность мира, в котором мы живем, когда организации, которая создает несколько веб-приложений и нативных приложений, необходимо выглядеть одинаково, не замедляя работу команды разработчиков. У Jina также есть курс про desigh токены, где в превью она написла:

С design токенами вы можете захватить низкоуровневые значения, а затем использовать их для создания стилей для вашего продукта или приложения. Вы можете поддерживать масштабируемую и совместимую визуальную систему для разработки пользовательского интерфейса.

Давайте возьмем пример: у вас, вероятно, есть шкала типографики, и вы хотите, чтобы она была одинаковой на нескольких платформах. Вместо того, чтобы хранить значения в файле CSS и повторять их в каждом приложении или веб-сайте, они могут быть сохранены в файле JSON, который затем будет преобразован в код, необходимый для всех других платформ. Что-то вроде этого:

{
  "global": {
    "type": "token",
    "category": "typography"
  },
  "aliases": {
    "TYPE_SIZE_SM": {
      "value": "14px"
    },
    "TYPE_SIZE_MD": {
      "value": "25px"
    },
    "TYPE_SIZE_LG": {
      "value": "44px"
    }
}

Вы можете написать свой собственный код, берущий этот файл JSON и преобразовывающий его во все переменные, которые вам могут понадобиться, например, файл Sass (или custom properties) будет зависеть от этих токенов и может использовать их как переменные для использования в другом месте в веб-приложении.

Я думаю, что это невероятно аккуратный материал. И вижу, как он экономит массу дублирующегося кода и путаницы между несколькими командами, поскольку он служит единым источником правды, в отличие от нескольких кодовых баз, имеющих одинаковые требования к дизайну и собственных таблиц стилей для обслуживания. Cristiano Rastelli писал об управлении токенами дизайна с помощью словаря стилей.

Ваш источник правды даже не должен быть файлом JSON! В посте, опубликованном ранее в этом году, Павел Лаптев показывает нам, как создавать токены в Figma, используя ее API, абстрагировать значения от макетов дизайна и использовать их в коде. Павел разбил свой документ Figma на отдельные страницы для своей сетки, отступов, палитры и типографики.

Сейчас кажется, что потребуются огромные усилия для настройки, но я считаю, что такие инструменты, как Sketch и Figma, сделают нам подобные вещи в ближайшем будущем проще - они, вероятнее всего, захотят, чтобы источник правды был в их конкретном инструменте дизайна вместо какого-то другого инструмента.

Последнее, что я хотел бы упомянуть - это сообщение Brent Jackson, в котором он высказал некоторые мысли о совместимости, когда речь заходит о разработке систем. В частности, он утверждает, что должна быть спецификация для design токенов, чтобы любая библиотека CSS-in-JS могла использовать этот код в любом формате или стиле.

Системные design токены должны быть гибкими и кроссплатформенными, что означает, что разные команды, разные реализации и разные библиотеки будут называть вещи по-разному. Для этого нужна спецификация. Хорошая совместимость может быть реализована, если бы мы например, назвали цвета нашей палитры colors и размеры шрифтов, которые мы используем fontSizes. Что вы делаете дальше, и какой формат данных вы используете для хранения этих значений, решать только вам. Преобразовать JSON в ES-модули, в YAML или даже TOML, если вам нужно. Это обычная структура данных, поэтому преобразование между другими структурами данных (например, дизайн инструментами или GraphQL API) также должно быть возможным.

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

В любом случае, я считаю, что design токены только начинают становиться мейнстримом, и их популярность вот-вот возрастет, так как эти инструменты, рабочие процессы и стандарты со временем становятся лучше - это все очень захватывающе!