Программирование с ИИ
ENRU
10.5

Постановка задач по интерфейсу

как описать словами то, что видишь глазами

Что это

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

Статья — про то, как сократить это расхождение.

Как сказать ИИ

Четыре части, как везде

Те же части, что в статье 3.2, но наполнение своё:

ЧастьДля интерфейса это
Контексткакие данные есть, откуда приходят, что уже написано
Цельчто пользователь видит и что может сделать
Ограничениячто не трогать, какие компоненты переиспользовать
Критерийпроверяемые состояния экрана

Описывай состояния, а не внешний вид

Главный приём главы. Любой экран с данными имеет минимум четыре состояния, и ИИ по умолчанию делает только одно — удачное.

Лучше
Экран списка подписок. Четыре состояния:

1. Загрузка — скелетон на три карточки
2. Пусто — текст «Пока нет подписок» и кнопка «Добавить»
3. Данные — список карточек
4. Ошибка — текст ошибки и кнопка «Повторить»

Все четыре должны быть реализованы, не только третье.
Не так
Сделай список подписок

Второй запрос даст только третье состояние. Загрузка, пустота и ошибка появятся потом — в виде багов у пользователей.

Называй структуру, а не пиксели

Не так
Карточка шириной 320 пикселей, отступ сверху 18, заголовок 17px
Лучше
Карточка: название города, под ним температура крупно,
внизу кнопка «Удалить». Карточки в ряд, на узком экране —
в столбец. Отступы из существующих переменных, новых
значений не вводи.

Пиксели — это магические числа (статья 8.3): подогнанные под один экран, они развалятся на другом.

Дай сигнатуру

Для React сигнатура — это интерфейс пропсов, и работает он так же, как в статьях 6.5 и 9.5:

Запрос
Компонент под такой интерфейс:

interface SubsListProps {
  subs: City[] | null;        // null = ещё загружается
  error: string | null;
  onRemove: (name: string) => void;
  onRetry: () => void;
}

Из типов видно все четыре состояния — реализуй их.

Это самая компактная форма задания: типы сами описывают, что бывает.

Проси по частям

Целый экран одним запросом — это пять задач в одной (статья 3.16). Лучше по шагам:

  1. компонент карточки с типами пропсов;
  2. список с состояниями загрузки и пустоты;
  3. обработка ошибки и повтор;
  4. адаптив.

После каждого шага — посмотреть. Это дешевле, чем разбирать готовый экран, в котором что-то не так.

На что смотреть

Сделано только удачное состояние. Проверяется просто: отключи сеть и посмотри, что на экране.

Придуманы отступы и размеры. Если в проекте есть переменные или система отступов, новые значения — это разнобой.

Компонент не переиспользует существующие. ИИ охотно пишет свою кнопку вместо той, что уже есть в проекте. Это причина 2 из статьи 3.1 — он её просто не видел.

Подписи придуманы. «Sorry, something went wrong» вместо текста на русском и в стиле остального интерфейса.

Доступность забыта. Те же div вместо button, нет подписей у полей (статья 8.2). React этого не исправляет.

Шпаргалка

  • Описывай состояния, а не внешний вид: загрузка, пусто, данные, ошибка.

  • По умолчанию ИИ сделает только «данные».

  • Структура вместо пикселей; отступы — из существующих переменных.

  • Интерфейс пропсов — самая компактная форма задания.

  • Есть макет или похожий экран — покажи, а не описывай.

  • Проси по частям и смотри после каждой.