Re: [webpayments] Should we expose status change events in the browser API? (#41)

The current event-based API for status changes does not allow enough freedom for websites that install handlers to perform asynchronous operations. For example, when a shipping address changes, what if the merchant website needs to perform an async request to obtain updated pricing information?

This could be mitigated by adding another method to the state machine or the event that the merchant has to call from their event handler once they are ready for the next state change to occur. Unfortunately, this is a bit complex and runs afoul of the direction the Web platform is heading with respect to promises.

Perhaps a better suggestion would be to avoid events all together and allow the merchant website to provide hooks that may return promises. This way, once the UA has performed an action, such as collecting an address, it can call the hook and wait for its promise to resolve before continuing.

However, even then, I feel that this API is failing to separate concerns and is therefore too prescriptive at its high-level. In my view, the use of events to monitor state changes in current API reminds me of XMLHttpRequest. XMLHttpRequest has been much maligned for its complexity and use of events to track state changes (among other things):

```
For more than a decade the Web has used XMLHttpRequest (XHR) to achieve asynchronous requests in JavaScript. While very useful, XHR is not a very nice API. It suffers from lack of separation of concerns. The input, output and state are all managed by interacting with one object, and state is tracked using events. Also, the event-based model doesn’t play well with JavaScript’s recent focus on Promise- and generator-based asynchronous programming.
```

https://hacks.mozilla.org/2015/03/this-api-is-so-fetching/

Because of these problems, a new API ([fetch](https://fetch.spec.whatwg.org/)) has been created that uses Promises and Streams to produce something that is both more low-level, more composable, less complex, and easier to use.

I fear we're repeating the same mistake with this API. We're using events to track state changes and it's suffering from a separation of concerns (eg: collection of address information from performing a payment). I don't feel like we're building a modern, low-level, composable API, rather we're constructing an old-style API where we are ignoring the lessons that others who are standardizing better APIs in the Web Platform have not. Again, see fetch or ServiceWorkers vs. AppCache as a perfect example of this.

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