Если я изменю порядок потоков
Я подозреваю, что это не сработает, потому что requestAnActionThatMayFail
является синхронным действием . Это объясняет, почему, поскольку merge
будет подписываться на предоставленные наблюдаемые последовательно , это означает, что если у вас есть
merge(
actionFailed$,
of(actions.requestAnActionThatMayFail()),
actionSuccess$,
)
и requestAnActionThatMayFail
успешно, он не будет работать, потому что actionSuccess$
еще не подписан (actionFailed$
подписан). Если requestAnActionThatMayFail
был асинхронным , вы не должны сталкиваться с этой проблемой.
или использовать concat
concat
, равный merge
с concurrent
установлен на 1. Хотя merge
может иметь несколько активных внутренних наблюдаемых, concat
может иметь только одну. Если установлен concurrent
, merge
будет буферизировать превышенные значения, а когда одна внутренняя наблюдаемая завершит , он примет самое старое буферизованное значение и создаст из него внутреннюю наблюдаемую величину.
Объяснение такой же, как в предыдущем разделе: другие наблюдаемые еще не подписаны .
Итак, вот мой подход:
const requestDelete = action$ => {
const actionSuccess$ = action$.pipe(
ofType(types.AN_ACTION_THAT_MAY_FAIL_SUCCESS),
take(1),
mergeMap(_ => of(actions.deleteSuccess()))
)
const actionFailed$ = action$.pipe(
ofType(types.AN_ACTION_THAT_MAY_FAIL_FAILED),
take(1),
mergeMap(_ => of(actions.deleteFailed()))
)
const requestDelete$ = action$.pipe(
ofType(types.REQUEST_DELETE),
mergeMap(action =>
from(SomeService.delete(action.payload)),
mergeMap(_ => of(actions.requestAnActionThatMayFail())),
catchError(err => of(actions.deleteFailed(err)))
),
// This seems a little redundant because of the previous `catchError`
// catchError(err =>
// of({ type: 'CRITICAL_REQUEST_DELETE_ERROR', err })
// )
)
// Make sure all the obs. are susbcribed
return merge(actionSuccess$, actionFailed$, requestDelete$);
}