Какова цель событий успешных / неудачных действий для асинхронных действий с ngxs?

Question

Примеры приложений для ngxs обычно отправляют отдельные успешные / неудачные действия для каждого асинхронного действия.

Например: https://github.com/tommythongnguyen/Ngxs-Pizza-Order/blob/master/src/app/products/store/pizzas.state.ts#L45

Для меня имеет больше смысла просто наблюдать за отправкой, если вы хотите подождать, пока действие завершится успешно / не удастся.

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

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

Stackblitz показывает мой предпочтительный подход: https://stackblitz.com/edit/angular-ngxs-so-question

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

Answer 1

Из моего опыта работы с NGXS мы использовали как ваш предпочтительный подход, так и в некоторых случаях явные действия, связанные с успехом / неудачей.

Мы использовали явные действия, как правило, когда одно государство хотело отреагировать на изменение в другом.

Например, в состоянии, которое захватывает некоторые общие справочные данные, но мы можем загрузить их только после того, как пользователь вошел в систему. Мы отправляем LoginSuccess действие, и есть ReferenceDataState ответьте на это, чтобы вызвать API и получить справочные данные.

Другой случай, который у нас есть, это то, что вызывающая сторона хочет знать некоторые данные, например, идентификатор объекта, созданного исходным действием. Магазины dispatch Функция возвращает Observable с возвращаемым типом void, поэтому мы можем использовать успешное действие, чтобы подобрать это значение результата.