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

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

Из чего состоят виджеты платформы

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

А что есть? А есть платформенные виджеты. В нашем случае существует четыре категории таких виджетов:

1. Примитивы — Суперпростые нефункциональные виджеты. Сюда входят вывод текста, иконки, картинки, свитчер слайдер и т. д.
2. WidgetWrapper — это по сути аналог frame из фигмы. Умеет как верстать виджеты внутри себя, задавать отступы, gap и т. п., так и окрашивать себе фон, обводку, менять скругления углов, управлять собственным позиционированием.
3. Пресеты на клиенте. Это те сущности, которые по каким-то причинам нельзя «собрать» на виджетах из пункта 1 и 2. Например, контейнеры всплывающих окон, карта, списки и сетки, контейнер webview.
4. Экран — контейнер со спец. слотами, всегда является корневым для верстки экрана приложения.

Важные особенности:

— За взаимодействие всегда отвечает WidgetWrapper. Он поддерживает различные типы взаимодействия, такие как: “статичный” (без взаимодействия), “нажми на меня” (фактически превращает в кнопку), “выдели меня” (checkbox), “выбери один из” (radio).

— Виджеты из 1-й группы не являются интерактивными сами по себе. Например, чтобы тот же переключатель мог переключаться, его необходимо обязательно поместить в WidgetWrapper с подходящим типом интерактивности.

— Визуализация взаимодействия также осуществляется WidgetWrapper, причем универсальным методом (пока это наложение цвета). Т. е. далее в виджетах нам не нужно прорисовывать hover, press и disable, всё делается платформой автоматически.

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

Свойство active

Важно запомнить, что это не то же самое, что и одноименные псевдокласс и свойство в CSS. В этом случае имеется в виду абстрактная “активность”. Активный виджет может быть интерпретирован по-разному: выбранный checkbox, активная вкладка, кнопка фильтров с активными фильтрами..

Как это работает

У WidgetWrapper и примитивов есть свойство active, которое может принимать значения true или false. Также существует логическое свойство active-inherit, которое, если установлено в true, делает свойство active данного виджета наследуемым от родителя.

У свойства active есть зависимые свойства. Например, active-background у враппера, active-icon у примитива IconBox и т.п. Даже есть active-context (приветпервой части).

Тут также важно сказать, что хоть дизайнер и настраивает все эти свойства, active управляется не из макета (верстки) а бизнес-логикой (с сервера).

Примеры

Ну что, достаточно теории, давайте посмотрим, как всё это работает на практике.

Пример1. Кнопка

Чтобы собрать кнопку, нам потребуется WidgetWrapper, виджет иконки и виджет текста. Собираем, настраиваем параметры, ставим тип интерактивности — press и получаем кнопку.

Теперь, допустим, мы хотим из этого шаблона получить зеленую кнопку «Фильтры». Меняем текст и иконку и выбираем нужный контекст (context=green).

А теперь последний штрих — настроим активные и обычные значения токенов и выберем активную иконку. И привяжем active к состоянию есть\нет активные фильтры.

Пример2. Checkbox & Radiobutton

Структура очень похожая на кнопку. Также враппер, иконка, текст. Но тип интерактивности уже выставить нужно check. Так с каждым нажатием на враппер будет переключаться собственное свойство active.

Получаем шаблон чекбокса.

Но теперь нам хочется, чтобы активный чекбокс был акцентным цветом. Для этого нужно поменять active-context у виджета иконки на green-accent. Получаем вот такое поведение.

Чтобы чекбокс превратился в Radiobutton, нужно поменять иконку на подходящую а также изменить тип интерактивности на radio. Теперь если, скажем, три таких виджета объединить во враппер, они будут работать как привычная всем группа радио-кнопок.

Пример 3. Segment control.

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

Всё как в кнопке, только с чуть другими стилями. И тип взаимодействия — radio. Оборачиваем в ещё один враппер, чтобы сегменты переключались в рамках группы, и получаем необходимый виджет. А переключая контексты, можем раскрашивать, как нам нравится.

Неактивность (disable)

Хотелось бы упомянуть, как в нашей системе реализовано свойство disable. Это отдельный наследуемый параметр, с несколько особенной логикой наследования. При установке параметра disable=true блокируется интерактивность у выбранного виджета и всех его «детей». Однако, значение их собственного свойства disable не перезаписывается. А для визуального отображения используется специальный контекст — inactive.

Это все наследуемые свойства на текущий момент. Другие интересные функции нашей дизайн-платформы я постараюсь описать в следующих статьях. Но вы можете не ждать выхода большого текста, а подписаться на мой телеграм-канал, и узнавать больше о развитии дизайнерской платформы ВкусВилл, SDUI, а также анонсы выступлений на митапах. https://t.me/uxflow

Концепция была разработана в рамках работы над дизайн-платформой для SDUI приложения ВкусВилл , и основной задачей было сократить количество параметров и возможных состояний виджетов, уменьшив таким образом дерево объектов, но при этом сохранить вариативность и управляемость. В дальнейшем, под платформой понимается решение, которое обеспечивает реализацию всех SDUI функций, т.е. технологии, а под дизайн-системой - решение по структурированию, иерархизации и оформлению пользовательских виджетов (пресетов).

О том, как применить подобный подход к цветовой семантике без SDUI на примере текущего приложения “ВкусВилл”, я писал в своем телеграм-канале.

Зачем нужны наследуемые свойства

Чтобы ответить на этот вопрос, нужно сначала разобраться, что такое SDUI. SDUI (Server Driven User Interface) - это концепция пользовательского интерфейса, управляемого сервером. Основная часть этой концепции относится не столько к дизайну, сколько к работе с данными и обработке действий пользователя. В традиционных приложениях вся обработка происходит на стороне клиента, включая большую часть бизнес-логики.

В SDUI-приложении клиент настолько “тупой”, что виджетам остается только отправлять события на сервер (например, “На меня нажали”) и ждать от него инструкций о том, как должен измениться интерфейс после этого действия. Вся бизнес-логика в этом случае выносится на серверную сторону.

А клиент умеет только работать с контрактом. Контракт - это чаще всего JSON-дерево объектов и их параметров. Такой подход позволяет вносить изменения на клиенте без выпуска новых версий приложения в магазины приложений. Чем более вариативен отрисовщик и чем более управляем интерфейс, тем больше видов изменений можно внести без выпуска новой версии.

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

Контракт

Контракт - это JSON, который передается с серверной части приложения на клиентскую и содержит параметры виджетов, которые на клиентской стороне преобразуются в элементы интерфейса.

Возьмем простой контракт из консервативного SDUI-приложения: кнопка с иконкой будет выглядеть следующим образом:

В целом, все достаточно компактно и понятно. Но что, если мы захотим изменить кнопку, изменить ее внешний вид и содержание? Нам придется охватить все параметры и, конечно же, выпустить новую версию приложения в магазинах. Мы же хотим избежать этого как можно дольше. Если мы возьмем, к примеру, JSON-макет простой страницы в Figma, а файлы Figma, как ни странно, в формате JSON, там будет более 800 тысяч строк 🤯.

Так насколько же наследуемые стили позволяют сократить размер контракта? Тот же экран, но уже оптимизированный под нашу платформу в формате JSON имеет всего около 1200 строк. Примерно так выглядит кнопка с иконкой и текстом в этом формате:

Значительно больше строк, чем в первом примере, но все еще читаемо, и внутри может быть все, что угодно. Мы не ограничены заранее определенными параметрами виджета кнопки. Таким образом нам удалось достичь вариативности макета как в Figma и в то же время существенно оптимизировать данные дерева объектов и их параметры.

Контекст (микротема)

Обычная структура семантического токена цвета в теме примерно следующая:

light-theme. background-brand-accent

Иногда к этому добавляется еще уровень токенов компонентов. Все имя токена полностью “лежит” в каком-либо параметре, например “button-background”. Цвет текста отдельно в свойствах “icon-color” и “label-color”, что-то вроде light-theme.text-color-on-accent.

В результате получаем зеленую кнопку.

Но контекст добавляет к этой картине новое измерение

За цвет в такой системе отвечают два свойства: одно для токена цвета и одно для его контекста. Значение контекста указывается в свойстве “context”, а в самом токене указывается только цвет. Например, в свойстве background указывается значение “primary”, а в свойствах text-color и icon-color указывается значение “on-primary”. По умолчанию значение свойства context равно “inherit”. Это означает, что виджет наследует значение контекста от родительского виджета. Если мы хотим, чтобы кнопка была зеленой, мы должны установить значение контекста на “green-accent”.

Контексты и цветовые токены в библиотеке Figma представлены в виде стилей и визуализируются в виде модулей:

Таким образом, правильное управление наследованием свойств позволяет легко управлять внешним видом компонента в коде, используя всего один параметр.

Как видно из приведенного выше примера, кнопка "В корзину" не меняет свой цвет, потому что у нее задан определенный контекст “green-accent”, а не “inherit”, и поэтому она не наследует контекст от своего родительского виджета.

Контексты в фигме

В коде с такими сложными механиками более менее все понятно, но как это реализовать в Figma? К сожалению, идеального решения не существует, даже с использованием новых variables. Сейчас у нас цвета на стилях, и даже если перейти на переменные, то без тарифа Enterprise картина кардинально не изменится. Теоретически, можно было бы попытаться создать mode для каждого контекста и разные коллекции для разных тем. Возможно, это сработало бы, но это очень затратно. Кроме того, в нашей платформе виджеты автоматически выгружаются на фронтенд, а это значит, что параметр также необходимо передавать.

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