AI и доступный DatePicker: почему 80% готового кода не хватает для production UI

DatePicker кажется простой задачей ровно до того момента, пока не появляются требования production-уровня: keyboard navigation, screen reader, ARIA-атрибуты, управляемое состояние, локализация, фокус, edge cases и тесты доступности. AI может быстро сгенерировать базовую структуру календаря, но именно последние 20% превращают компонент из демо в нормальный интерфейс.

Есть два принципиально разных подхода: попросить AI сделать компонент по принципу «80/20» или проектировать системно вместе с агентом. Второй вариант ближе к зрелой frontend-разработке: модель полезна, но без архитектурного контроля она легко генерирует красивый, но хрупкий UI.

Почему DatePicker сложнее, чем кажется

У DatePicker много скрытых требований. Пользователь должен уметь открыть календарь, перемещаться по датам клавиатурой, понимать текущую выбранную дату через screen reader, закрывать popup, возвращать фокус и не терять состояние формы.

Типичные проблемы AI-сгенерированного варианта:

• фокус прыгает непредсказуемо;
• Tab, Enter, Escape и стрелки работают неполно;
• screen reader озвучивает не то или молчит;
• ARIA-атрибуты есть, но применены формально;
• состояние даты дублируется в нескольких местах;
• обработчики конфликтуют;
• нет тестов на accessibility-сценарии.

Визуально компонент может выглядеть готовым. Но для пользователя клавиатуры или screen reader он будет сломан.

Где AI действительно помогает

AI хорошо справляется с генерацией стартового кода: разметка календарной сетки, функции работы с датами, базовые стили, обработчики кликов, варианты API компонента. Это ускоряет начало.

Также модель полезна для:

• составления чеклиста accessibility;
• генерации тестовых сценариев;
• объяснения ARIA-паттернов;
• поиска edge cases;
• рефакторинга повторяющейся логики;
• подготовки Storybook stories.

Но AI не должен быть единственным источником архитектурных решений. Особенно в UI-компонентах, где поведение важнее внешнего вида.

Системный подход с агентом

Более надёжный путь — сначала описать контракт компонента. Например:

• controlled или uncontrolled режим;
• формат значения;
• поддержка min/max date;
• локализация;
• поведение при выборе даты;
• keyboard shortcuts;
• требования WCAG;
• интеграция с form library;
• тестируемые сценарии.

После этого AI можно использовать как помощника, который реализует отдельные части, а не придумывает весь компонент за один prompt.

Хороший prompt для агента должен быть не «сделай DatePicker», а «реализуй roving tabindex для календарной сетки по такому контракту, не меняя public API, добавь тесты на стрелки и Escape».

Какие тесты нужны

Для доступного DatePicker мало snapshot-тестов. Нужны поведенческие проверки:

• открытие с клавиатуры;
• перемещение стрелками;
• выбор даты через Enter/Space;
• закрытие через Escape;
• возврат фокуса;
• корректные aria-label для дат;
• озвучивание выбранного значения;
• работа disabled dates;
• проверка axe или аналогичным инструментом.

Если AI генерирует код, тесты становятся ещё важнее. Они фиксируют ожидаемое поведение и не дают модели случайно сломать accessibility при следующем рефакторинге.

Архитектура компонента

Удобно разделить DatePicker на слои:

• date utils: вычисление месяца, недель, ограничений;
• state machine: открыто/закрыто, focused date, selected date;
• UI primitives: input, popup, grid, cell;
• accessibility helpers: labels, roles, keyboard map;
• integration layer: form state, validation, locale.

Такой компонент проще сопровождать. AI можно давать задачи по слоям: например, улучшить date utils или добавить тесты для keyboard map, не затрагивая остальное.

Практические правила работы с AI в UI

1. Не принимайте компонент без ручного keyboard-теста.
2. Проверяйте screen reader хотя бы на базовых сценариях.
3. Требуйте от AI тесты вместе с кодом.
4. Не генерируйте весь сложный компонент одним prompt.
5. Фиксируйте public API до реализации.
6. Разделяйте визуальные стили и поведение.
7. Проверяйте ARIA по документации, а не по уверенности модели.

Итог

AI может сильно ускорить frontend-разработку, но доступный UI требует инженерной строгости. DatePicker — хороший пример: первые 80% легко получить за минуты, а последние 20% определяют, можно ли компонент отдавать пользователям.

Правильная роль AI — не заменить frontend-инженера, а ускорить рутину, помочь с вариантами и подсказать тесты. Ответственность за поведение, доступность и архитектуру всё равно остаётся на команде.