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

If it's something that can happen multiple times, and it isn't a stream (chunks of data that form a whole), then events are the right primitive.

So XHR's "load" example is a poor example, it should be a promise. XHR's "progress" events should be a stream.

However, address change sounds like an event to me. It can happen multiple times. It isn't a stream. Sure the developer is likely to need to respond async, but we handle that in service worker using `waitUntil`:

```js
self.addEventListener('sync', event => {
  event.waitUntil(
    doSomeStuff()
  );
});

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match('/')
  );
});
```

Both `waitUntil` and `respondWith` take a promise. This means the API knows that an action completes, when it fails, and what the eventual value is, which is useful in the case of `respondWith`.

Sounds like `shippingaddresschange` would work in a very similar way.

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