Re: [webpayments] What is the appropriate conversational pattern for the API? (#55)

@adrianba 's latest PR is definitely an improvement. Thanks also to @jakearchibald for his input.
 
I still don't like using events to effectively make a request (as opposed to signal an event) but I will concede that this pattern, combined with the use of a promise as the return value, appears to be gaining popularity for asynchronous comms across an API boundary on the Web platform.

If the event object has an `updateWith` method that takes a promise (as it's now designed to do) the website can at least respond immediately. 

_**SIDENOTE**: I wonder if the `updateWith(Promise<PaymentDetails> d)` signature could be less restrictive so that the website could simply pass in the result of calling `fetch`?_

I would still like to see some description in the spec of what should happen if the event is emitted and there are no listeners and include some timeout behaviour. 

I interpreted @dlongley 's comment to be alluding to a related question about inter-dependancy between events:

> I don't think that approach fully solves problems like having shipping options depend on shipping address choices

If the next step that the browser UI flow must take is dependent on getting a response from the website (i.e. the user has picked an address and the shipping address changed event has been emitted and the browser is waiting for a list of shipping options from the website) then:

 1. What is the behaviour of the browser UI which it seems must remain disbled for input while it waits? Are we happy to leave this to the implementors to figure out?
 1. What is the behaviour of the browser if the website never resolves the promise and much of this should we define in the spec?

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/55#issuecomment-184171347