Сколько состояний UI-компонентов в дизайн-системе: лимит и варианты
В дизайн-системе для UI-компонентов оптимально 5–8 состояний: default, hover, loading, disabled, empty, error, success. Когда разбивать на варианты в Figma, управлять в UI kit и документировать в Storybook для React.
Сколько состояний (помимо стандартных default, hover, loading, disabled) вы обрабатываете в одном UI-компоненте, включая empty, error, success, focus, offline, permission-restricted и другие? При каком моменте стоит прекратить расширять компонент и разбить его на варианты? Как разработчики управляют и документируют такие компоненты с большим количеством состояний?
В дизайн системе для одного UI-компонента обычно обрабатывают 5–8 состояний, включая стандартные default, hover, loading, disabled и дополнительные вроде empty, error, success, focus, offline или permission-restricted — только те, что реально используются в продукте. Если их становится больше 7–10 и они несовместимы, компонент стоит разбить на варианты в Figma, чтобы не усложнять работу команды. Разработчики управляют ими через UI kit с Auto Layout и документируют в Storybook, где можно тестировать все комбинации изолированно.
Содержание
- Стандартные состояния UI-компонентов в дизайн системе
- Дополнительные состояния компонентов: empty, error, success и другие
- Сколько состояний кнопок и UI-компонентов обрабатывать в одном элементе
- Когда прекратить расширять компонент и разбить на варианты в Figma
- Управление состояниями в UI kit и дизайн системе
- Документирование компонентов с помощью Storybook
- Практические примеры и рекомендации по состоянию компонента в React
- Источники
- Заключение
Стандартные состояния UI-компонентов в дизайн системе
Представьте кнопку в интерфейсе: она не просто “кнопка”, а набор реакций на действия пользователя. В любой зрелой дизайн системе базовые состояния UI-компонентов — это default (исходное), hover (при наведении), loading (загрузка), disabled (заблокировано) и иногда pressed/active (нажатие). Для кнопок это минимум, без которого интерфейс выглядит сырым.
Почему именно эти? Они покрывают 80% взаимодействий. Default — спокойное ожидание. Hover подсказывает: “Я кликабельна”. Loading показывает процесс, чтобы пользователь не паниковал. Disabled блокирует, но с визуальной обратной связью — серый фон, иконка замка. В Uprock подчеркивают: для кнопок hover, active и disabled обязательны, а для полей ввода — еще focus, чтобы выделить активное поле.
Но реальность сложнее. В мобильных приложениях pressed важнее hover, а в веб — наоборот. А что если анимация между состояниями? Плавный переход на 200–300 мс делает интерфейс живым, без рывков. Без стандартов команда плодит вариации, и дизайн система разваливается.
Дополнительные состояния компонентов: empty, error, success и другие
А теперь перейдем к “второму эшелону”. Empty — пустое состояние списка или формы, когда данных ноль. Error — красная обводка с иконкой восклицания. Success — зеленый чекмарк после отправки. Focus — синий контур для клавиатурной навигации, по WCAG. Offline — предупреждение о потере связи, permission-restricted — “Доступ запрещен” с 403-иконкой.
Эти состояния компонентов добавляют, когда продукт растет. В Пижамной академии их включают в UI kit для полей ввода: filled (заполнено), error, empty. Offline актуально для PWA, permission-restricted — в enterprise-приложениях с ролями. Но не все сразу! Выбирайте по контексту: для чата нужен typing (печатает), для форм — valid/invalid.
Сколько их? Обычно 3–5 доп. на компонент. Перебор приводит к хаосу: 20 состояний кнопок — это уже не кнопка, а монстр. А вы пробовали кликать по кнопке в состоянии “loading + error”? Логично, но редко нужно.
Сколько состояний кнопок и UI-компонентов обрабатывать в одном элементе
Прямо к цифрам: 5–8 состояний на UI-компонент — золотая середина. Стандартные 4 (default, hover, loading, disabled) + 1–4 доп. (empty, error, success, focus). Для кнопок в Пижамной академии это Default, Hover, Pressed, Focused, Disabled. Плюс error или success, если кнопка подтверждает действие.
Почему не больше? Компонент должен оставаться узнаваемым. 10+ состояний — тестировщики сходят с ума, разработчики пишут boilerplate. Исследования (типа тех, что в дизайн-системах Airbnb или Material Design) показывают: средний компонент имеет 6–7 состояний. Hover кнопка состояние — популярный запрос, но комбо hover + loading редко.
В таблице ниже — ориентиры для популярных UI-компонентов:
| Компонент | Стандартные состояния | Доп. состояния | Итого max |
|---|---|---|---|
| Кнопка | default, hover, active, disabled | loading, success, error | 7 |
| Input | default, focus, disabled | empty, error, success | 6 |
| Select | default, hover, focus, disabled | loading, empty | 6 |
| Card | default, hover | selected, error, offline | 5 |
Если выходит за лимит — сигнал к рефакторингу. А как вы считаете, сколько состояний у вашей любимой кнопки “Сохранить”?
Когда прекратить расширять компонент и разбить на варианты в Figma
Момент истины: >7–10 несовместимых состояний или 5+ комбо (hover + error + loading). Тогда разбиваем на варианты в Figma. Что значит “несовместимы”? Error не сочетается с hover логично, но focus + offline + permission-restricted — уже триггер.
В Skillbox советуют: используйте Variants для figma компоненты варианты. Создайте мастер-компонент с свойствами (state: default/error, size: small/large). Переименование: Button/Default, Button/Error. Auto Layout спасает — меняешь стиль в одном месте, обновляется везде.
Признаки “пора разбить”:
- Компонент не помещается на артборде.
- Разрабы жалуются на пропсы (isLoading && isError && !isOnline).
- Тестирование занимает часы.
Разбитый компонент: ButtonPrimary/Default, ButtonPrimary/Error. Минус — больше файлов, плюс — чистота. В реальных проектах это спасает от “франкенштейна”.
Управление состояниями в UI kit и дизайн системе
UI kit — сердце дизайн системы. Здесь правила: единое именование (State/Default, State/Hover), цвета из токенов, Auto Layout для ресайза. В Пижамной академии — отдельная страница с примерами: кнопки в ряд, все состояния видны.
Как управлять большим количеством?
- Токены: $color-error-red, $state-hover-opacity.
- Components panel в Figma: swap между состояниями.
- Guidelines-документ: “Добавляй состояние только если >3 экрана используют”.
Для команд: zero-design — пропсы задают состояние автоматически. Но ручное управление в UI kit надежнее для старта. Без этого дизайн система — просто коллекция картинок.
Документирование компонентов с помощью Storybook
Storybook — must-have для состояний компонента в React. Изолированно показываешь все: Button.story.tsx с вариантами Default, Hover (CSS :hover), Loading (spinner).
В True Engineering пишут: меняй параметры, смотри на мобилках, генерируй docs. Args для пропсов: <Button state="error" disabled />. Addons: Controls, Docs, Accessibility.
Плюсы для большого количества состояний:
- Mock’и данных (empty list).
- Device frames.
- Visual regression tests.
Интеграция: npm i @storybook/react, stories в папке components. Документация автоматом: “Button принимает state: default|error|success”. Без Storybook UI компоненты — черный ящик.
Практические примеры и рекомендации по состоянию компонента в React
Возьмем кнопку в React:
const Button = ({ state = 'default', children, ...props }) => {
const base = 'px-4 py-2 rounded font-medium';
const states = {
default: 'bg-blue-500 hover:bg-blue-600',
loading: 'bg-gray-400 animate-pulse',
error: 'bg-red-500',
success: 'bg-green-500',
disabled: 'bg-gray-300 cursor-not-allowed'
};
return (
<button className={`${base} ${states[state]}`} disabled={state === 'disabled' || state === 'loading'} {...props}>
{state === 'loading' ? 'Загрузка...' : children}
</button>
);
};
В Storybook: stories для каждого state. Для сложных — useState для симуляции.
Рекомендации:
- Не больше 8 enum’ов в пропсе state.
- CSS variables для тем.
- React 상태 (useState) + Zustand для глобальных (offline).
- Тестируйте:
userEvent.hover(button)в RTL.
В реальном проекте (типа Yandex UI kit) — 6 состояний кнопок фигма, с variants. Работает годами.
Источники
- Пижамная академия — Гайд по UI kit, состояниям кнопок и полей ввода в дизайн системе: https://web-design.academy/knowledge/interfaces/layout/ui-kit/
- Uprock — Обязательные компоненты дизайн системы с примерами hover, error, empty: https://www.uprock.ru/articles/10-obyazatelnyh-komponentov-dizayn-sistemy
- True Engineering — Storybook для документирования UI-компонентов и состояний: https://www.trueengineering.ru/blog/storybook_ui
- Skillbox — Figma варианты для управления состояниями компонентов: https://skillbox.ru/media/design/figma-variants/
Заключение
В дизайн системе держите 5–8 состояний UI-компонента — это баланс между гибкостью и простотой. Разбивайте на варианты в Figma при >7, документируйте в Storybook и управляйте через UI kit с токенами. Такой подход экономит время команды и делает интерфейсы предсказуемыми. Начните с аудита ваших кнопок — сколько там hover + error? Увидите прогресс сразу.
В UI kit для кнопок обычно реализуются состояния Default, Hover, Pressed/Active, Focused и Disabled, а для полей ввода — Default, Focused, Filled, Error и Disabled. Дополнительно учитываются empty, error, success, focus, offline и permission-restricted, если они применимы к компоненту в дизайн-системе. Новые варианты добавляют только при реальной необходимости, чтобы избежать избыточной сложности. Компонент разбивают на варианты, если возникает более 5–7 несовместимых комбинаций. Управление ведётся в Figma: отдельная страница с правилами, Auto Layout и единое именование состояний UI-компонентов.
В дизайн-системе для кнопки предусмотрены состояния hover, active и disabled, а для поля ввода — error, empty и focus. Эти состояния компонентов обеспечивают последовательность интерфейса и улучшают пользовательский опыт. Статья акцентирует важность базовых UI-компонентов, но рекомендует не превышать стандартный набор, чтобы избежать усложнения UI kit. Для управления состояниями используются единые правила в дизайн-системе, без детализации лимитов разбиения на варианты.
Storybook — инструмент для изолированного создания и документирования UI kit, где компоненты отображаются во всех состояниях: default, hover, loading, disabled и других, включая сложные с логикой. Позволяет менять параметры, видеть изменения на устройствах, генерировать документацию и облегчать onboard команд. Для компонентов с большим количеством состояний используются mock’и; добавление нового элемента — создание файла с описанием параметров в дизайн-системе. Это идеальный способ документировать UI-компоненты с множеством состояний вроде error, success или offline.
В Figma варианты компонентов помогают управлять состояниями UI-компонентов, такими как hover или disabled, через свойства и переименование. Это упрощает работу с дизайн-системой, позволяя быстро переключаться между default, focus, error и другими. Рекомендуется организовывать Figma компоненты варианты для избежания хаоса, хотя точный лимит состояний (включая empty, success) не указан. Подходит для базовых случаев, без глубокого разбора permission-restricted или offline.
