{"id":14273,"url":"\/distributions\/14273\/click?bit=1&hash=820b8263d671ab6655e501acd951cbc8b9f5e0cc8bbf6a21ebfe51432dc9b2de","title":"\u0416\u0438\u0437\u043d\u044c \u043f\u043e \u043f\u043e\u0434\u043f\u0438\u0441\u043a\u0435 \u2014 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0435 \u0442\u0440\u0435\u043d\u0434\u044b \u0440\u044b\u043d\u043a\u0430 \u043d\u0435\u0434\u0432\u0438\u0436\u0438\u043c\u043e\u0441\u0442\u0438","buttonText":"","imageUuid":""}

3 подхода к созданию компонентов

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

Компонент списков, или list item – это компонент, на котором может строиться большая часть мобильных интерфейсов.

Скриншоты трех приложений, состоящие из списков

У него могут быть сотни вариантов: список настроек, способы оплат, профили пользователя и прочее…

Вариации List Items

В дизайн-системах я встречала три подхода к созданию такого компонента:

1. Первый и самый очевидный подход – сделать нужные list items и дополнять их в процессе работы. Пример из UI Kit Uber:

Base Gallery Figma Community

Этим удобно пользоваться: можно настроить варианты и переключать их через правую панель или заменять компоненты с зажатым Opt+Cmd из панели Assets.

Минусы тоже есть. Дизайнер Jérôme Benoit из Doctolib пишет:

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

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

2. Второй подход – со скрытыми слоями. Состояния компонента настраиваются включением или выключением его слоев.

Возможно, этот способ появился, когда в Figma еще не было вариантов. Сейчас такой подход не оправдан, потому что копии компонента со скрытыми слоями занимают столько же памяти, что и мастер. Об этой проблеме писала студия Mish:

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

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

Как и в первом случае, этот способ приводит к потере скорости работы по мере роста системы.

3. Третий подход – максимально настраиваемый компонент. В мастер-компоненте закладываются слоты, куда выводятся компоненты с набором нужных интерфейсных элементов.

Схема компонента

Например, на схеме в позиции lead, trail 1 и trail 2 выводится один и тот же компонент item, который в свою очередь содержит: варианты с чекбоксами, радио, аватарами, изображениями банковских карт, иконки, переключатели и лейбл.

Структура компонента Item

В контентную часть выводится текстовый компонент, содержимое которого может быть включено или выключено по такому же принципу.

Это простой пример. Компонент может быть сильно сложнее – с большим количеством слотов и дополнительными настройками в виде отступов и типов выравнивания контента, бордеров и прочего.

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

Минус – возможно понадобится больше времени, чтобы продумать структуру мастер-компонента и настроить правильное отображение дочерних

0
10 комментариев
Написать комментарий...
Дом Техника

Полезная статейка. Автору моя благодарность

Ответить
Развернуть ветку
Dmitry Kapustin

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

Ответить
Развернуть ветку
Михаил Скворцов

а зачем варианты сокращать? Они для этого и созданы. Не загружают макет по слоям = меньше нагрузка при рендере
+быстро можно настроить, что нужно
Инструмент для этого и был предназначен

Ответить
Развернуть ветку
Михаил Скворцов

Еще минус 3-го. Могут из этого собирать Франкенштейна. Энтропия явно будет выше, чем в готовом компоненте на вариантах

Ответить
Развернуть ветку
Женя Жуланова
Автор

Согласна )

Ответить
Развернуть ветку
Bitepix

Ну и четвёртый вариант - figma properties (пора бы уже разбираться). А вообще нужен баланс и всякие карточки да списки все же делать компонентов под каждый кейс и не строить франкенштейнов ради того что бы на одном экране из тысячи включить кнопку

Ответить
Развернуть ветку
Женя Жуланова
Автор

Можно просто писать, что есть ещё один подход, можете почитать про него в моей статье https://vc.ru/426827. :))

Сама концепция замены компонентов через properties вызывает вопросы. Может пострадать консистентность дизайна. Потом будут с ней работать как в том меме.

Ответить
Развернуть ветку
Яся Зайцев

Женя, вам случайно дизер не нужен? готов работать за еду и выходных дни.

Ответить
Развернуть ветку
Женя Жуланова
Автор

Яся, у нас нет еды, только рубли 😅 Можете прислать резюме мне в телеграм: julanova или на почту: [email protected].

Ответить
Развернуть ветку
Женя Жуланова
Автор

1

Ответить
Развернуть ветку
7 комментариев
Раскрывать всегда