Re: [w3c/payment-request] fine grained error recovery for fields (#647)

Regrettably, @mnoorenberghe's proposal would have been great if we were not already returning `response` from `.show()` (i.e., if we would have designed the API like that initially). 

However, introducing the event leaves `const response = await request.show();`  in a strange place, specially when you try to wire everything up. We effectively end up with two sources for the `response`, and it means developers would need to wrap the `request.onpaymentauthorized` in a promise that guards against premature completion (as below, I am personally not a big fan): 

```JS
const request = new PaymentRequest();
const canContinue = new Promise(resolve => {
  request.onpaymentauthorized = event => {
    const errorFields = checkResponse(event.response);
    if (errorFields.length) {
      event.updateWith({
        details,
        errorFields,
      });
      return;
    }
    resolve();
  };
});
// This is somewhat messy
// because now I'm holding promises instead of awaiting them :(
const showPromise = request.show();
await canContinue;
const response = await showPromise;
const status = processPayment(response);
response.complete(status);
```

Definitely, could make the above leaner by doing what @mnoorenberghe does in his example above (do the `.compete()` logic in the handler itself)... but, as I said, I think we missed that opportunity with the current design that returns `response` from `await request.show()`.  

Other cons would be having to introduce a new EventHandler interface type, as well as an attribute. While  `.retry()` only adds a single method and could work well with the existing state machine. 

Now, API design aside, a larger problem when retrying will be figuring out the restrictions on what can actually be fixed... If the `shippingAddress` is not serviceable, then what does picking a new one do (specially because it could change the total, and now the `request` is in a "close" state - so effectively dead)? Does the `request` again wake up and get put into an "interactive" state? 

Need to think more about the above, or see how ApplePay is handling it. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/647#issuecomment-350186416