W3C home > Mailing lists > Public > public-payments-wg@w3.org > February 2016

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

From: Jake Archibald <notifications@github.com>
Date: Fri, 12 Feb 2016 03:26:28 -0800
To: w3c/webpayments <webpayments@noreply.github.com>
Message-ID: <w3c/webpayments/issues/41/183285478@github.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:14 UTC