Интерактивные компоненты в Figma: как связать варианты реакцией Change to
Компонент с состояниями — это набор вариантов плюс реакции между ними.
В прототипе достаточно одной реакции, чтобы кнопка стала интерактивной.
Что нужно на входе
Практика: сначала компонент с вариантами.
Без набора компонентов интерактивность не собрать: реакция работает не между отдельными элементами, а между вариантами одного набора.
Варианты и набор
Документация: варианты объединяются командой Combine as variants в один набор компонентов.
Практика: набор — это контейнер, внутри которого лежат состояния. Каждое состояние — отдельный вариант.
Реакция Change to
Документация описывает путь: вкладка Prototype в правой панели, затем перетаскивание от рамки к нужному варианту.
Второй способ: в разделе Interactions создать взаимодействие, выбрать действие Change to и указать вариант в списке.
Практика: перетаскивание быстрее, список точнее — особенно когда вариантов много.
Триггер
Практика: без триггера реакция не сработает.
Триггер — это событие: клик, наведение, нажатие клавиши. Документация: настройки триггера и действия правятся в панели Interaction.
Когда это работает
Практика: только в режиме просмотра прототипа.
На холсте вы видите варианты, а не поведение. Проверять надо запуском презентации — иначе легко решить, что реакция не работает.
Порядок сборки
- Создайте компонент.
- Сделайте вариант для второго состояния.
- Объедините их в набор.
- Перейдите на вкладку Prototype.
- Свяжите состояние с состоянием.
- Выберите триггер.
- Запустите прототип и проверьте.
Практика: шаг 7 обязателен. Без него вы не знаете, что связь вообще установилась.
Сколько вариантов
Практика: чем больше состояний, тем больше связей.
Шесть состояний — это тридцать потенциальных переходов, если связывать всё со всем. На практике нужны только осмысленные: наведение, нажатие, отключённое состояние.
Документация по наборам прямо советует не раздувать количество: свойство с несколькими значениями лучше дробить на отдельные.
Свойство или вариант
Практика: не каждое различие стоит делать вариантом.
Документация: набор вариантов — для визуально разных состояний, а для скрытия элемента или подмены иконки есть свойства компонента.
Это снижает количество связей и делает набор читаемым.
Ограничение прототипа
Практика: реакция меняет вариант у экземпляра, но не отменяет его свойства.
Если у экземпляра переопределены текст или иконка, они сохраняются при переключении. Это удобно: кнопка меняет цвет, а подпись остаётся.
Где это применяется
Кнопки. Обычное, наведение, нажатие.
Поля ввода. Пустое, заполненное, с ошибкой.
Чекбоксы и переключатели. Включено и выключено.
Вкладки. Активная и неактивная.
Практика: начинать стоит с кнопки. Она простая и сразу показывает, работает ли схема.
Где ломается
Нет набора компонентов. Связывать нечего.
Забыт триггер. Реакция не срабатывает.
Проверка на холсте. Кажется, что не работает.
Слишком много связей. Набор невозможно поддерживать.
Вариант вместо свойства. Набор растёт без пользы.
FAQ
Какая реакция нужна?
Change to.
Где её настраивать?
На вкладке Prototype в правой панели.
Можно ли связать экземпляры разных компонентов?
Нет, реакция работает внутри набора вариантов.
Как проверить?
Запустить прототип и нажать на элемент.
Сохранятся ли переопределения?
Да, текст и подмена вложенного экземпляра остаются.
Именование вариантов
Практика: имя варианта — это его свойство.
Документация: свойства и значения задаются в наборе, и каждый вариант обязан быть уникальной комбинацией. Имя вроде «Primary Large Default» превращается в четыре значения, а не в одно длинное название.
Практика: чем чище имена, тем понятнее панель у экземпляра и тем меньше ошибок при сборке прототипа.
Проверка связей
Практика: связи удобно проверять глазами по линиям на холсте.
Если линия идёт не туда, это видно сразу. Если линий нет вообще, значит реакция создана в другом месте или не создана.
Практика: перед показом макета пройдите все состояния по кругу. Обычно находится одно-два, из которых нельзя выйти.
Перенос в код
Практика: набор вариантов хорошо ложится на свойства компонента в коде.
Документация прямо говорит о соответствии свойств и значений свойствам кода, что упрощает передачу разработчику.
Практика: называйте свойства так, как они будут называться в коде: Size, State, Type. Тогда при передаче не придётся переводить словарь.
Отличие от Smart Animate
Практика: это разные механизмы, и путать их дорого.
Change to подменяет вариант — переход мгновенный. Smart Animate анимирует разницу между двумя состояниями.
Если нужна плавная смена цвета, одной реакции достаточно: смена произойдёт без анимации. Если нужен именно переход, потребуется второй механизм.
Практика: начинайте с простой подмены. Анимация добавляется тогда, когда без неё прототип не читается.
Размер набора
Практика: набор из восьми вариантов ещё обозрим.
Дальше стоит задуматься: часть различий наверняка выносится в свойства. Кнопка с иконкой в трёх положениях и двумя размерами — это шесть вариантов, а с цветовыми состояниями уже двенадцать.
Практика: правило простое — вариантов должно быть столько, сколько нужно для прототипа, а не для всех теоретических комбинаций.
Итог
Интерактивность в Figma собирается из двух частей: набор вариантов и реакция Change to между ними.
Практика: объединить состояния, связать осмысленные переходы, задать триггер, проверить в прототипе. Всё остальное — свойства компонента, а не варианты.
Что видит разработчик
Практика: прототип — не спецификация.
Разработчику нужен не клик по кнопке, а список состояний и правила переходов. Набор вариантов как раз и даёт этот список: каждая ячейка набора — отдельное состояние.
Практика: если состояние нельзя описать словами, значит вариант лишний или склеен с другим.
Работа в команде
Практика: набор компонентов — общий ресурс.
Изменение в основном компоненте расходится по экземплярам, и это одновременно удобство и риск: правка, сделанная для одного экрана, ломает другой.
Практика: состояния добавляйте осознанно, а переименования свойств согласовывайте — они видны всем, кто использует набор.
Триггеры на практике
Практика: самый частый триггер — клик.
Наведение и нажатие нужны там, где прототип имитирует реальное поведение: меню по наведению, эффект нажатия у кнопки. Для демонстрации логики хватает клика.
Практика: не смешивайте триггеры в одном компоненте без нужды. Если кнопка реагирует и на наведение, и на нажатие, проверяйте оба сценария отдельно.