Лучшие практики для отображения и управления сообщениями об ошибках в приложении React-Redux

Question

Я создаю приложение React (с act-redux , redux-saga и ax ios), и мне нужен совет о том, как организовать мой проект для отображения удобных сообщений об ошибках.

Я должен решить, что я показываю пользователю.

В частности, я хотел бы получить ответы на следующие вопросы:

1. Если Я отображаю сообщение на основе кода состояния?
2. Где хранить сообщения об ошибках: в самом компоненте, в файле конфигурации (хотелось бы увидеть пример такого файла)?
3. Должен ли я разбить ошибки на клиент / сервер / другие ошибки и почему? (на основе пример от Ax ios)
4. Как будет выглядеть мое дерево состояний редуксов?
5. Должен ли я отправлять действие для каждой ошибки на основе кода состояния?

Буду признателен за любые предложения или примеры из реальной жизни.

Вот несколько примеров сообщений об ошибках от серверной части:

Request URL: https://example.com/api/call/123
Request Method: POST
Status Code: 400 Bad Request

Request URL: https://example.com/api/call/123
Request Method: PUT
Status Code: 409 Conflict

Request URL: https://example.com/api/user/me/
Request Method: GET
Status Code: 401 Unauthorized

Answer 1

1) Предполагая, что вы также выполняете BE или можете попросить кого-то скорректировать ответ - может быть лучше вернуть тело с вашим ответом об ошибке API и избегать только кодов состояния HTTP - если это возможно. Затем он может содержать «код» ошибки, который отображается на сообщение в вашем интерфейсе, а также имя поля, которое может быть действительно полезным для отображения ошибок в нужном месте в формах, например, c. альтернативно, все сообщение может исходить от BE, и FE просто отображает его. Я работаю над кодовой базой корпоративного уровня, в которой используются оба этих метода.

2) Что касается сообщений об ошибках, я бы всегда сохранял их в общем файле, но кроме этого, на ваше усмотрение. Это зависит от того, как вы реализуете # 1. Лично мне нравятся «коды ошибок», хранящиеся в файле enum, которые соответствуют сообщению, потому что затем вы можете делать другие логи c из этого (например, не отображать остальную часть формы, если ошибка X вызвана, используйте пользовательский сообщение для кода ошибки в одной ситуации или возврат к значению по умолчанию

3) Не уверен - я думаю, вы бы сделали это, если хотите регистрировать ошибки на стороне сервера, но показывать клиент. Думаю, там, где я работаю, мы различаем чисто разные категории журналирования.

4) Опять же, зависит от вашей реализации - в некоторой степени от вас. Некоторые пакеты форм будут обрабатывать это для вас в избыточном количестве. Другие будут использовать для этого только локальное состояние, а не избыточное.

5) Имеет смысл, да. Опять же, если вы посмотрите специальный код ошибки, возвращенный в теле вызова API, который даст вам большую гибкость.

Я надеюсь, что это даст вам некоторые идеи, основанные на моем опыте, а не на каком-либо заданном мышлении.

также обратите внимание на https://reactjs.org/docs/error-boundaries.html, и, если вы еще не использовали REST APIS / рекомендации по API REST: https://blog.restcase.com/rest-api-error-codes-101/

Answer 2

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

1. В большинстве случаев пользователи не заботятся о коде состояния. Если вы не хотите указывать слишком много c, тогда вы можете отобразить простое предупреждение / снэк-бар, например: «Извините, произошла ошибка ".

2. Если вы уверены, что вам нужно показывать определенные c ошибки пользователю, я определенно рекомендую постоянный файл для ошибок, в котором будут храниться все ваши сообщения об ошибках, вы можете хранить их в каталоге констант в папке store, так что, возможно, даже в / helpers, это зависит от вашего выбора.

3. Да, вы можете определенно разделить свои ошибки на основе, если ошибка была включена сервер или на стороне клиента.

4. Я не думаю, что дерево избыточности изменится, если вы не управляете ошибками в дереве. Если вы хотите, обязательно используйте снэк-бар / редуктор оповещений в верхней части дерева

5. Возможно, вы не захотите показывать одну и ту же ошибку для кода состояния в каждом из различных компонентов, В противном случае, если вы хотите, вы можете использовать его, но это добавит много ненужного кода в ваши запросы.

Для наших проектов, так как мы используем i18 для интернационализации, у нас есть редуктор снэк-бара и папка действий. Мы импортируем действия снэк-бара в наши саги и просто отображаем простое сообщение об ошибке (вы определенно можете настроить его для своих нужд соответственно), вот и все, сделайте его простым.

yield put(Actions.apiRequest);
try {
  const res = yield axios.put('/todo/', updateData);
  if (res.data.status === 'success') {
    yield put(Actions.fetchTodos(todoID));
    yield put(snackbarSuccess('Todo Saved Successfully !'));
  } else {
    throw new Error();
  }
} catch (error) {
  yield put(Actions.apiError);
  yield put(snackbarError(REQUEST_FAIL)); // an imported constant
}

Некоторый базовый c код позади моей реализации.