Обработчик ошибок с потоком

У меня есть приложение React.js, которое я рефакторинг для использования архитектуры Flux, и я пытаюсь понять, как обработка ошибок должна работать, придерживаясь шаблона Flux.

В настоящее время при возникновении ошибок запускается событие jQuery "AppError", а общий помощник по обработке ошибок, который подписывается на это событие, помещает на экран пользователя Flash-сообщение, записывается на консоль и сообщает об этом через вызов API. Приятно, что я могу вызвать ошибку по любой причине из любой части приложения и обработать ее согласованным образом.

Я не могу понять, как применить аналогичную парадигму с архитектурой Flux. Вот два конкретных сценария, с которыми я борюсь.

1) Ошибка вызова API

Все мои вызовы API сделаны из создателей действий, и я использую обещание отправить сообщение об ошибке (IE 'LOAD_TODOS_FAILED') при сбое. Магазин видит это событие и обновляет его состояние соответствующим образом, но у меня все еще нет моего общего поведения ошибки из моей предыдущей итерации (уведомления и т.д.).

Возможное разрешение:

Я мог бы создать ErrorStore, который связывается с действием LOAD_TODOS_FAILED, но это означает, что каждый раз, когда у меня возникает новый тип ошибки, мне нужно явно добавить это действие в ErrorStore, вместо того, чтобы все ошибки обрабатывались автоматически.

2) Магазин получает неожиданное действие

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

Возможные разрешения:

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

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

  • Создайте ControllerView для обработки ошибок, который подписывается на каждый Store

    Я могу определить свойство errors в каждом хранилище, а затем просматривать View каждый Store и действовать только на свойство errors. Когда свойство errors не равно null, оно может отправлять новые действия и т.д. Недостатками являются то, что мне нужно помнить о том, чтобы каждый магазин сохранял это представление при создании новых, и каждый магазин должен иметь свойство ошибки, которое ведет себя одинаково путь. Он также ничего не делает для устранения сбоев API-вызовов.

Есть ли у кого-нибудь предложенный подход для общего обработчика ошибок, который вписывается в архитектуру Flux?

TL; DR

Мне нужно обрабатывать ошибки в большинстве Action Creators and Stores. Как настроить согласованную обработку ошибок, которые будут возникать для любого типа общей ошибки?

Ответы

Ответ 1

  • Ошибка API

Если вы хотите избежать перечисления всех ошибок в ErrorStore, вы можете иметь общее действие APP_ERROR и иметь свойства этого действия, которые описывают его более подробно. Тогда ваши другие магазины просто должны были бы изучить эти свойства, чтобы узнать, подходит ли действие к ним. Не существует правила, согласно которому зарегистрированный обратный вызов в магазинах должен быть сфокусирован на типе действия или только на типе - это просто самый удобный и последовательный способ определить, действительно ли действие имеет значение.

  1. Магазин получает неожиданное действие

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

Ваше второе решение звучит хорошо, но опасная вещь, о которой вы упомянули, - "Когда свойство errors не равно null, оно может отправлять новые действия и т.д." - опять же вы не хотите выпускать действия в ответ на другие действия, Это путь боли, который Flux стремится избежать. Ваш новый вид контроллера просто получит значения из магазинов и ответит, представив правильный вид.

Ответ 2

Старый поток, но для чтения потомков, я думаю, что хранилище, предназначенное для ошибки, является вашим ответом для # 1.