teach retry() about payerErrors

[marcoscaceres]

BUILDS ON #720 - This is part 2 of 5. It adds:

• retry() argument for validation errors: retry(PaymentValidationErrors errorFields)
• PaymentValidationErrors dictionary
• PayerErrorFields dictionary
• Adds shippingAddressErrors to PaymentValidationErrors

The following tasks have been completed:

• [x] Confirmed there are no ReSpec errors/warnings.
• [x] Added Web platform tests
• [ ] added MDN Docs (link)

Implementation commitment:

• [ ] Safari (link to issue)
• [ ] Chrome (link to issue)
• [ ] Firefox (link to issue)
• [ ] Edge (public signal)

Impact on Payment Handler spec? Unknown.

Example

Via payerErrors, the user now knows what's actually wrong with the payment.

async function doPaymentRequest() {
  const request = new PaymentRequest(methodData, details, options);
  const response = await request.show();
  try {
    await recursiveValidate(request, response);
  } catch (err) { // retry aborted.
    console.error(err);
    return;
  }
  await response.complete("success");
}

async function recursiveValidate(request, response) {
  const promisesToFixThings = [];
  const payerErrors = await validatePayerInput(response);
  if (!payerErrors) {
    return;
  }
  await response.retry({ payerErrors });
  return recursiveValidate(request, response);
}

doPaymentRequest();

---

Preview | Diff

[marcoscaceres]

Blocked on #720 landing.

[marcoscaceres]

For anyone watching at home, this currently lacks (coming soon as new PRs/parts):

• interfacing with updateWith() - in particular, errors need to reject the retryPromise.
• "payerdetailschange" event, onpayerdetailschange on PaymentResponse, and associated task to fire the event.

[marcoscaceres]

Friendly ping, @domenic.

[marcoscaceres]

See your point, and don’t want us to spend time bike shedding. I’ll change them all in an upcoming PR 🙂

On 25 Jun 2018, at 1:53 pm, Domenic Denicola notifications@github.com wrote:

@domenic commented on this pull request.

LGTM editorially, but I'm increasingly unhappy with the excessive prefixing and suffixing.

Step away from your particular coding style, which uses lots of redundant variables and object literal shorthand. Consider what more conventional code using this API would have to look like:

await response.retry({ shippingAddressErrors: { addressLineError: "Bad address line" }, payerErrors: { payerEmailError: "Bad email" } }); This is fairly ridiculous. The field names here are something like errors.payerErrors.payerEmailError, instead of the simpler errors.payer.email or even errors.payerEmail. (Similarly, errors.shippingAddressErrors.addressLineError instead of errors.shippingAddress.addressLine---the latter is long enough already.)

I'd really suggest getting rid of all the redundant prefixes and suffixes, and allowing people to write clean, straightforward code of the sort

await response.retry({ shippingAddress: { addressLine: "Bad address line" }, payer: { email: "Bad email" } }); If you don't see my point, maybe it's something to bring up with a larger audience to get more perspectives?

In index.html:

@@ -3210,8 +3211,9 @@

Set response.[[\retryPromise]] to retryPromise.

• In the payments UI, indicate to the end-user that something is
• wrong with the user-provided data of the payment response.
• By matching the members of errorFields to input fields
• in the user agent's UI, indicate to the end-user that something is
• wrong with the data of the payment response. Maybe discuss how the UA should use the developer-supplied strings?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[marcoscaceres]

Filed https://github.com/w3c/payment-request/issues/736 to drop *Error.

[marcoscaceres]

Tests https://github.com/web-platform-tests/wpt/pull/12395