3 подхода к созданию компонентов
Привет, VC! В прошлый раз я описала маленький хак для работы над дизайн-системами. В этой статье опишу три подхода к созданию компонентов на примере списков.
Компонент списков, или list item – это компонент, на котором может строиться большая часть мобильных интерфейсов.
У него могут быть сотни вариантов: список настроек, способы оплат, профили пользователя и прочее…
В дизайн-системах я встречала три подхода к созданию такого компонента:
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, который в свою очередь содержит: варианты с чекбоксами, радио, аватарами, изображениями банковских карт, иконки, переключатели и лейбл.
В контентную часть выводится текстовый компонент, содержимое которого может быть включено или выключено по такому же принципу.
Это простой пример. Компонент может быть сильно сложнее – с большим количеством слотов и дополнительными настройками в виде отступов и типов выравнивания контента, бордеров и прочего.
Плюсы такого подхода – не нужно делать кучу айтемов, как в первом решении, и не будут создаваться копии ненужных слоев, как во втором решении.
Минус – возможно понадобится больше времени, чтобы продумать структуру мастер-компонента и настроить правильное отображение дочерних
Полезная статейка. Автору моя благодарность
у меня варианты еще больше размножаются так как для двух мобильных операционок надо сделать, и еще dark mode подержать, хочется и варианты сократить, но с другой стороны нравится пользоваться настройками в правой панели
а зачем варианты сокращать? Они для этого и созданы. Не загружают макет по слоям = меньше нагрузка при рендере
+быстро можно настроить, что нужно
Инструмент для этого и был предназначен
Еще минус 3-го. Могут из этого собирать Франкенштейна. Энтропия явно будет выше, чем в готовом компоненте на вариантах
Согласна )
Ну и четвёртый вариант - figma properties (пора бы уже разбираться). А вообще нужен баланс и всякие карточки да списки все же делать компонентов под каждый кейс и не строить франкенштейнов ради того что бы на одном экране из тысячи включить кнопку
Можно просто писать, что есть ещё один подход, можете почитать про него в моей статье https://vc.ru/426827. :))
Сама концепция замены компонентов через properties вызывает вопросы. Может пострадать консистентность дизайна. Потом будут с ней работать как в том меме.