Как стать автором
Обновить

Дизайн-токены способны на большее: создаем единый источник информации о компонентах UI

Время на прочтение14 мин
Количество просмотров18K
Всего голосов 19: ↑19 и ↓0+19
Комментарии10

Комментарии 10

Ещё немного, и вы изобретёте css.

ммм, да нет, не претендуем. Цели этого подхода несколько большие, чем просто организация свойств компонент веба
НЛО прилетело и опубликовало эту надпись здесь
Кнопка была одним из первых компонентов в дизайн-системе, поэтому (хотя казалось бы, должно быть наоборот) токенов для нее достаточно мало — высота, толщина границы, радиус скругления. Все остальное, на самом деле, там особо и не нужно. Текст внутри — это отдельная компонента со своими токенами, иконка — тоже. Чего не хватает и стоило бы добавить — например, отступ между иконкой и текстом, внутренние отступы. Это значения, естественно, тоже не захардкожены в стилях, но для них используется совсем абстрактный токен $token-spacer

Элементы ввода (input, textarea ) — там токенов чуть больше. Тоже как минимум высота, внутренние отступы, ширина границы. Но при этом мы не можем использовать внутри компоненты типографики. Также размер иконок в полях обычно фиксированный. Это привело нас к хранению размера шрифта, line-height, размера иконки. Все остальное уже зависит от этих значений обычно.

Строки — это специальная компонента типографики, которая может иметь один из нескольких типов — H1, H2, P1, P2, P3 и т.д. (на самом деле, это почти все, что нам надо). И для каждого типа токенов 2 — размер шрифта и высота линии

На начальных этапах развития системы мы больше использовали абстрактные токены ($token-spacer) для отступов, т.к. боялись чрезмерно усложнить систему, плюс потребителей ее было не очень много. Последние компоненты описываются уже только специфическими токенами (которые уже могут быть связаны с универсальными — $token-input-padding-horizontal = $token-spacer-small), т.к. мы поняли, что это не страшно и более удобно, особенно когда надо поменять стиль на всех компонентах на всех платформах одновременно.
НЛО прилетело и опубликовало эту надпись здесь
Нам было бы не жалко, но по большому счету это не имеет смысла, так как несмотря на то, что все используют одни и те же компоненты (идеологически), у всех разные требования к ним. У кого-то у кнопок будут тени, у кого-то — позиция иконки, у кого-то — еще какие-нибудь параметры. Поэтому Кристиано говорит в первую очередь об идее.

Поделиться непосредственно дизайн-системой, возможно, стоит, но она пока тоже довольно специфичная. А вот про то, чтобы открыть какие-то внутренние инструменты для работы с токенами, мы подумаем. Тем более, что у нас команда увеличилась, и ресурсы на поддержку открытого кода могут быть. Я передам идею разработчикам.
НЛО прилетело и опубликовало эту надпись здесь
Вообще дизайн-систем довольно много в открытом доступе (ссылки есть в начале статьи), даже если их код скрыт. Как минимум можно ориентироваться на их подходы, а уж написать простой скрипт, который будет превращать один массив в другой под необходимые нужды, мне кажется, не очень сложно
Не является ли такая система опасной? Я поменял толщину границы для кнопки к примеру, а в итоге, в одном месте из 100 изза этого поехала разметка?
Ну так можно сказать про любое изменение CSS при любом подходе.

Нам в работе избегать такого позволяют несколько вещей:
— использование как можно более простых компонентов и грамотное их использование с учетом специфики проектов
— поддержание этих компонентов нейтральными и изолированными
— vrt-тесты на сами компоненты и их композиции
Зарегистрируйтесь на Хабре, чтобы оставить комментарий