Какова цель событий успешных / неудачных действий для асинхронных действий с 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

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

Answer 1

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

Где мы использовали явные действия, как правило, там, где у нас было одно состояние, желающееответить на изменение другим.

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

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