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`:

self.addEventListener('sync', event => {

self.addEventListener('fetch', event => {

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:

Received on Friday, 12 February 2016 11:26:56 UTC