HTML в дизайн-системах

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

Токены — это атомарные значения дизайна (color: blue-500, spacing: 16px). Компоненты — переиспользуемые единицы HTML+CSS+JS (кнопка, модальное окно, TextField). Типовые решения — это композиции более высокого уровня (форма входа, карточка содержимого с аватаром). Структура HTML фиксирована на уровне компонента, а типовые решения объединяют компоненты.

Компоненты воплощают лучшие практики: каждая кнопка использует элемент <button> (а не div) с правильным атрибутом type. Каждое модальное окно удерживает фокус, поддерживает клавишу Escape и имеет правильные роли ARIA. Внедрение компонентов избавляет от необходимости заново реализовывать доступность для каждой функции продукта.

Storybook отображает каждый компонент изолированно с разными свойствами и вариантами. Дизайнеры и руководители продукта видят доступные компоненты, не читая код, а разработчики — примеры использования, не разыскивая их в исходном коде. Это фактический стандарт документации дизайн-систем.

Относитесь к дизайн-системе как к пакету, публикуемому по правилам семантического версионирования. Ломающие изменения HTML/CSS (например, переименование класса CSS, от которого зависят пользователи, или удаление слота компонента) требуют увеличения мажорной версии. Пользователи пакета обновляются намеренно и по собственному графику, а не неожиданно для себя.

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

Токены обеспечивают темизацию: замените карту цветовых токенов, и каждый компонент получит новую палитру. Выпуск под разными брендами (общие компоненты с разным оформлением) становится простым, когда всем управляют токены, а компоненты ссылаются на токены, а не на жёстко заданные значения.

Для организаций, использующих несколько фреймворков (React, Vue, Angular), веб-компоненты предлагают одну реализацию, работающую повсюду. Создавайте их с помощью Lit, FAST или на чистом JS, а используйте одинаково в любом фреймворке. HTML-структура — это контракт, а не фреймворк.

Дизайн-системы один раз встраивают доступность в каждый компонент: обработку клавиатуры, роли ARIA, управление фокусом и цветовой контраст. Команды продуктов, использующие систему, получают доступность автоматически, вместо того чтобы создавать её для каждой функции с нуля, — это измеримо сокращает количество ошибок доступности во всей компании.

Отслеживайте, какие продукты используют какую версию дизайн-системы. Такие инструменты, как каталог компонентов Backstage, собственные боты Slack, отслеживающие package.json, или простые внутренние панели показывают, где последняя версия ещё не внедрена. Показатели внедрения помогают обосновать дальнейшие инвестиции.

Решите, кто может добавлять компоненты: только центральная команда дизайн-системы? Распределённые изменения от команд продуктов? У каждой модели есть свои компромиссы. Центральные команды выпускают изменения медленнее, но поддерживают качество; распределённые команды работают быстрее, но рискуют раздробить систему. Принимайте решение осознанно, учитывая масштаб организации.

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

Почему токены дизайна (например, color: blue-500, spacing: 16px) предпочтительнее жёстко заданных значений внутри компонентов?

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