Хранение компонентов

А вот и компонентная часть дизайнерской документации. Она отвечает только за исходники и подойдет для токенов, сеток, ui-элементов, иконок, кейвижуалов, готовых экранов и паттернов проектирования.

Структура

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

Но есть совет, который подойдет на все времена — не храните все в одном месте, так файл станет тяжелым и неповоротливым. Файл будет долго загружаться, в нем будет трудно ориентироваться и все это создаст неприятный developer experience.

Старайтесь логично поделить содержимое, например:

Создайте отдельные библиотеки, если есть какой-то крупный обособленный набор компонентов, например:

В отдельные файлы можно выделить:

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

Наполнение

Этот курс не ставит перед собой задачу и не претендует на поиск идеальной и единственно правильной сборки компонентов. Собрать компоненты можно по-разному, и каждый вариант будет иметь право на жизнь. Поэтому, рекомендую читателю самостоятельно подойти к решению этого вопроса. На рынке много профессиональных команд с образцовыми ui-китами, вы можете взять за основу любой из них. Мы же не будем изобретать велосипед и возьмем за основу Simple Design System.

Tokens

Начнем с токенов. Мы специально выделяем их в отдельную библиотеку для гибкости в переиспользовании. Например, у вас две библиотеки компонентов для платформ web и mobile, и набор токенов для этих библиотек идентичен, либо очень похож, соответственно нет смысла поддерживать два набора токенов в каждой из этих библиотек. И все станет только хуже, если количество платформ начнет расти, что если вы начнете поддерживать часы, тв или банкоматы. Можно пойти через Tokens Studio. На момент написания курса у плагина не было интеграции с Figma Variables. Поэтому придется выбирать, либо то, либо другое. Автор выбирает нативный подход.

Посмотрим на организацию токенов в SDS. Ликбез по токенам

Color:

Introduction Docusaurus

Responsive:

Introduction Docusaurus

Size:

Introduction Docusaurus

Исследуйте, пробуйте, тестируйте и находите подходящее вам решение.

Компоненты

В рамках функциональных возможностей Фигмы обеспечьте максимальную производительность: библиотека компонентов должны открываться на просмотр максимально быстро. Не храните тяжелые файлы в библиотеке, не добавляйте лишних слоев, оптимально соберите варианты компонентов. Гайд по сборке компонентов. Consta

А в рамках нашей идеологии инструментов обеспечьте максимальную информативность добавив ссылки на все дополняющие материалы:

Introduction Docusaurus

Где гайдлайн это ссылка на страницу с гайдом по компоненту:

Introduction Docusaurus

Бэклог, ссылка на бэклог с фильтром по компоненту:

Introduction Docusaurus

Сторибук, ссылка на страницу компонента в Сторибуке:

Introduction Docusaurus

Пропсы

Обращайте внимание на синхронизацию и пропсов между Фигмой и витринами компонентов. Все пропсы доступные в Фигме должны быть доступны и в витринах, на «живом» компоненте:

Introduction Docusaurus

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

Например, компонент List Operation имеет одинаковый набор пропсов на мобильном и веб-представлениях:

Introduction Docusaurus

Иногда, в связи со специфичностью платформ, так может не получиться, тогда задача дизайн-системы объяснить, каким образом осуществить миграцию в конкретном случае.