Я использую redux-observable для обработки действия:
export const createPaymentMethod =
(getBraintreeToken: (Object) => Promise<*>, cardholderName: string) => ({
type: CREATE_PAYMENT_METHOD,
getBraintreeToken: () => getBraintreeToken({ cardholderName }),
});
const mapBraintreeError = err => Observable.of({
type: CREATE_PAYMENT_METHOD + FAILURE,
error: { response: err.message },
});
export const createPaymentMethodEpic = (action$: any, store: ReduxState) =>
action$.ofType(CREATE_PAYMENT_METHOD)
.switchMap(({ getBraintreeToken }) => Observable.fromPromise(getBraintreeToken()))
.switchMap(({ nonce }) =>
ajax(api.createPaymentMethod(store.billings.info.customer_id, nonce))
.mapSuccess(CREATE_PAYMENT_METHOD)
.mapFailure(CREATE_PAYMENT_METHOD),
)
.catch(mapBraintreeError);
Что я делаю, так это намеренно делаю getBraintreeToken()
Promise невыполненным. Это приводит к тому, что эпическая функция выполняет catch
и возвращает действие CREATE_PAYMENT_METHOD + FAILURE
. Что я и намеревался.
Проблема в том, когда я пытаюсь вызвать эпик во второй раз. Он не выполняется...
РЕДАКТИРОВАТЬ: я преобразовал эпик, и теперь он работает, однако я до сих пор не понимаю, почему первый пример был сломан (на самом деле мне больше нравится плоская структура первого эпика).
export const createPaymentMethodEpic = (action$: any, store: ReduxState) =>
action$.ofType(CREATE_PAYMENT_METHOD)
.switchMap(({ getBraintreeToken }) =>
Observable.fromPromise(getBraintreeToken())
.switchMap(({ nonce }) =>
ajax(api.createPaymentMethod(store.billings.info.customer_id, nonce))
.mapSuccess(CREATE_PAYMENT_METHOD)
.mapFailure(CREATE_PAYMENT_METHOD),
)
.catch(mapBraintreeError),
);
mapTo
илиmap
, чтобы избежать использования обнаружения ошибок в качестве основного пути. Зависит от того, что внутриgetBraintreeToken()
и как генерируется сообщение об ошибке. Не могли бы вы выложитьgetBraintreeToken()
(если все еще охотитесь за оптимизацией). - person Richard Matsen   schedule 12.01.2018getBraintreeToken
из внешнего API, поэтому мне, вероятно, придется обернуть его в какое-то другое обещание, чтобы избежать блокировки блокировки... - person Tomasz Mularczyk   schedule 12.01.2018