Рабочий подход
Список участников может нормально работать с короткими именами и всё же терять меню действий при длинном email. Break UI прослеживает каждое отображаемое значение до props, фикстур или данных API, проверяет допустимые пределы и подменяет данные на той же границе. Он не меняет вёрстку только ради создания сбоя.
Сравнение должно оставаться проверяемым: переключайтесь между демо- и худшими данными, а при необходимости используйте отдельные состояния пустого, одного элемента и большого списка. Отчёт различает нечитаемый или недоступный контент, визуальные повреждения и хрупкие допущения; он также фиксирует то, что выдержало проверку.
Ожидаемые результаты
- Инвентаризация полей с источниками, ограничениями и необязательными значениями
- Фикстуры худших случаев и переключатель наборов данных только для разработки
- Приоритизированные сбои, предлагаемые исправления и решения для владельца
От входных данных к выводам
- 01Сопоставьте каждое отображаемое значение
Прочитайте компонент, правила валидации и структуры API. Запишите ограничения и поведение при отсутствии полей, включая счётчики, бейджи, изображения и длину списка, а не только текстовые поля.
- 02Создайте правдоподобные крайние случаи
Объедините длинные и короткие имена, отсутствующие поля и локализованные подписи в фикстуре той же структуры, что и существующие данные. Используйте пределы схемы, если они известны, а для неограниченных полей зафиксируйте это, не выдумывая предел.
- 03Сравнивайте в реальных размерах
Держите переключатель в разработке или на прототипном маршруте. Проверьте фактический контейнер компонента, 320px и самую широкую раскладку, а также увеличенный текст; добавьте тёмную тему и RTL, если продукт их поддерживает.
- 04Сначала отчёт, потом исправления
Для каждого сбоя укажите серьёзность, провоцирующее значение, предлагаемое исправление и расположение в файле. Остановитесь для решений вроде переноса или обрезки текста; применяйте исправления только по запросу, затем повторно проверьте демо- и экстремальные состояния.