На Хабре уже есть статьи про качество кода (линты, хинты, хорошие практики), стратегии обработки ошибок (feature toggle, request retry) и UX/UI их отображения.

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

До того, как ошибка попала в прод

Тестировщики пишут тесты. В рамках этих тестов они работают с версткой. Их работа станет сильно проще если они смогут писать селекторы коротко и очевидно.

• Уникальные идентификаторы
  Все информационные и управляющие компоненты должны содержать уникальный идентификатор (id или data-test-id).

• Микро разметка данных
  Некоторые выбранные значения лучше дублировать в верстке через "микро-разметку". Например, Avito таким образом дублирует информацию, указанную в объявлении и это, в том числе, сильно облегчает написание парсеров страницы.

• Состояние асинхронных операций
  Компонент loader было бы неплохо снабдить каким-нибудь атрибутом, по которому можно было бы легко понять, что в данный момент идет загрузка данных и она ещё не завершена.

В момент ошибки

Большая часть ошибок фронта, которые мне приходилось разбирать в проде, сводилась к отсутствию данных или их не верному типу:

• Входные данные
  Сервер всегда может не прислать данные или прислать их не в том формате (например: массив строк, вместо строки).

• Типизация входных аргументов
  Если что-то пошло не так в одной функции, то в любую другую на входе может прилететь неожиданный тип (например: undefined вместо string). Проверяйте тип и попытайтесь привести его к нужному.

Многие разработчики привыкли к описанию типа на TS и забывают, что это всего лишь «документация» и по факту тип может не совпасть. Чаще всего не совпадают строки и массивы, поэтому используйте || и ?.

После того, как ошибка произошла

• Изоляция проблемных участков
  Хорошо, если страница состоит из слабосвязанных компонентов и ошибку можно перехватывать в рамках одного куска UI. Тогда его можно заблокировать и оставить в доступе остальной функционал. Для этого было бы не плохо написать единый компонент-обертку с функцией перехвата ошибки и стандартной заглушкой. Возможно даже добавить кнопку «попробовать снова»

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

• Авто-формирование отчёта об ошибке
  Если контакт саппорта представлен в виде email, добавьте авто-формирование текста письма с тех. описанием (через кликабельную ссылку mailto). Таким образом, можно автоматом описать шаги воспроизведения бага, версию браузера и т.п., т.к. пользователи могут просто не написать об этом.

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

• Логирование
  При каждом перехвате какой-либо ошибки можно дергать URL бекенда для сохранения информации об ошибке (кидать туда стек трейс, адрес страницы и прочую информацию). Таким образом, можно узнать о багах, с которыми не обращаются в саппорт.

• Экран заглушки
  Если сервер в целом перестал отвечать, можно подготовить экран-заглушку. Так фронт самостоятельно сообщит пользователю о проведение «технических работ» и попросит подождать, а не просто зависнет с белым экраном. Подробнее про заглушки можно прочитать тут.

Через неделю

• Запись запросов и ответов
  Часто, разработчик, который исправляет ошибку, не имеет доступ к данным прода или не может повторить комбинацию данных, которая выпала у пользователя. Было бы не плохо, если бы фронт записывал последние 10..20 запросов к бекенду и в случае ошибки мог выгрузить их в файл. Этот файл можно было бы приложить к багу и на основе этих запросов воспроизвести баг без бекенда.
  
  Особенно, это становится удобным, при наличии нескольких тестовых стендов или долгоживущих багов. Можно просто «отыграть» запросы локально без всяких пере-логинов и пере-подключений. Кроме того, часто оказывается, что ошибка была в данных бекенда.

• Обезличивание логов
  В дополнение к прошлому пункту, можно добавить небольшую функцию, которая уберет персональные данные из сохраненных запросов. Это сразу снимет часть вопросов от ИБ (позволит проще передавать файл лога и работать с ним)
  
  Кроме того, иногда бывает полезно иметь такой переключатель в интерфейсе. Например, в системах статистики люди иногда не хотят показывать саппорту конкретные числа. Мы добавили галочку «обезличить данные» и стали получать больше описаний ошибок со скриншотами.

• Запись последовательности нажатых кнопок
  В самом начале был совет присваивать id элементам управления. Если все используемые кнопки на сайте берутся из одного компонента, то мы можем добавить в onClick сохранение последних 10..20 нажатых кнопок. Это так же упростит нам последующий разбор бага или аварии, т.к. пользователь может не верно описать свои шаги по воспроизведению (например, не упомянуть двойной клик или быстрый переход между двумя компонентами)