There is strange action we dispatch called CARD_SUBMISSION_ERRORS. It's odd because it's tightly coupled to the card form entry and that creates complications like this in actions/subscriptions.js:
fetch(...).fail($xhr => {
...
if (allErrors && arrayHasSubString(allErrors, 'already subscribed')) {
dispatch(notificationActions.showError({
errorCode: errorCodes.ALREADY_SUBSCRIBED,
...
}));
} else if (data.pay_method_nonce) {
dispatch({
type: actionTypes.CREDIT_CARD_SUBMISSION_ERRORS,
...
});
}
});
This code has to make a decision whether to dispatch a credit card related error or just a general app error.
What really needs to happen is this: tell the form that initiated the form processing that an error occurred.
I think the processing state introduced by #421 is a good pattern for this. The code would need to be expanded and dispatches would probably look more like this:
fetch(...).fail($xhr => {
dispatch(processingActions.stopProcessing(
processingId,
{wasError: true, errorResult: $xhr.responseJSON}
));
});
The state reducer would need updating too and components will need to check for ongoing processing more like processingState[processingId] && processingState[processingId].inProgress.
With that, both the transaction subscribe component and any credit card entry component can receive the change in processing state by looking for processingState[processingId].errorResult.