frontend-ui-engineering

frontend-ui-engineering — навык Addy Osmani для создания и изменения production-интерфейсов, компонентов и страниц, где важны доступность, отзывчивый layout, состояние, производительность и аккуратное визуальное исполнение. Он предназначен не только для нового UI: область применения включает рефакторинг существующих компонентов, responsive-разметку, требования WCAG и ситуации, когда результат должен соответствовать реальной дизайн-системе, а не выглядеть как случайный шаблон. Отправная точка — понять действующую систему проекта и строить контентный интерфейс вокруг пользовательской задачи. В архитектуре рекомендуется держать связанные части компонента рядом: реализацию, тест, story и hook находятся в одной папке, когда они действительно существуют. Предпочтение отдаётся композиции вместо компонента с большим числом конфигурационных флагов. Компонент должен делать одну понятную работу, а получение данных и отображение разделяются там, где это снижает связанность: container обрабатывает загрузку, ошибку и пустое состояние, presentation-компонент получает уже подготовленные данные. При выборе состояния используется простая лестница: локальный useState для состояния одного компонента, lifted state для нескольких соседей, Context для редких записей и частых чтений вроде темы, URL-состояние для фильтров и пагинации, server state для удалённых данных и глобальный store только для сложного общего состояния. Prop drilling глубже трёх уровней предлагается избегать. Визуальные решения должны следовать существующей дизайн-системе. Навык отдельно предупреждает против типичных признаков шаблонного AI-интерфейса: одинаковой фиолетовой палитры, чрезмерных градиентов, повсеместных больших скруглений, generic hero-секций, placeholder-копирайта, чрезмерных отступов, бездумных карточных сеток и тяжёлых теней. Вместо этого используются реальные токены проекта, согласованная шкала spacing и иерархия typography. Заголовки h1, h2 и h3 не должны пропускать уровни, а цвет не должен быть единственным способом передать состояние. Контент и реальные строки нужно учитывать заранее, потому что именно они выявляют переносы и переполнение, которые скрывает lorem ipsum. Accessibility в навыке оформлена как практическая часть реализации. Интерактивность должна работать с клавиатуры; для действия предпочтителен настоящий button, а не кликабельный div. Иконкам без видимой подписи нужны aria-label, поля получают label или понятный aria-label, а при открытии изменившегося контента фокус переводится в правильное место. Пустые, ошибочные и loading-состояния не должны оставлять белый экран: нужны понятные сообщения, retry или следующий шаг. Для контентной загрузки предлагается skeleton, а не бесконечный spinner. Верификация включает отсутствие ошибок в console, обработку loading/error/empty и проверку клавиатурной навигации. Responsive-подход начинается с мобильного layout и расширяется через breakpoint-ы. В качестве проверочных размеров указаны 320, 768, 1024 и 1440 пикселей; это не повод добавлять лишние режимы, а минимальный набор для проверки поведения. Хороший результат сохраняет смысловую и визуальную иерархию, читабельность, доступность и работоспособность на разных ширинах. Навык не обещает универсальную компонентную библиотеку и не заменяет конкретные правила проекта: он задаёт проверяемые принципы для архитектуры, состояния, визуального языка, WCAG и QA, а используемые framework, tokens и инструменты должны быть подтверждены самим репозиторием.