Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42)

@adrianba,

> Events are used when something may happen multiple times. Promises can only be resolved once.

While that is a difference between events and promises, I do not think it's the most important one. Events are used to observe or react to an external process that you don't have control over; when there is no imperative API for asserting control. An event API makes a lot of sense for stream based systems, for example, where there is an external I/O process and you want to capture some incoming data or other kinds of events -- but you don't directly control the transfer of that incoming information.

Promises are merely an asynchronous analog for imperative synchronous programming. When you make an imperative call, you pass some parameters and get a result. A Promise just lets you do this asynchronously; the result is returned to you at some later point in time through the resolution of the Promise. The caller is in control.

The problem I have with the paymentrequest API is that control over the payments process is turned over *too soon*. The merchant website should have complete control over how to structure its own payment request, but it loses some of that control by handing over an "incomplete" payment request to get things started. Since the site has more to say before the payment request is actually ready, this introduces a need in the API to allow the merchant site to wrestle some of that control back. This is currently implemented by combining a synchronous event system, which I believe is a tool for a different kind of job.

The problem with this design becomes immediately apparent when the merchant site decides they need to do some asynchronous process in order to properly control the payment request. They can't do this with a synchronous event system, so now control needs to be handed back to the merchant site anyway, by pausing further processing until an imperative call is made by the site. This is a good indication that the API is too prescriptive and will lead to frustration or the leakage of further implementation details such as state information that the merchant site should not need to deal with at all.

All of this indicates to me that we should completely separate different composable parts of the flow (separation of concerns, simpler, lower-level API). Now, there is a concern over keeping the user experience simple as well. But I think the way to do that would be to keep the control in the merchant site -- but make it so the merchant site can "start a flow" and then make the related API calls they want to make to modify the flow and move it along as the merchant sees fit. This makes the browser bits act as if they are receiving events *from the merchant site* instead of the other way around. That seems like the correct approach to me and it removes the complexity from the merchant site.

---
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/42#issuecomment-173628517