Service Worker APIs as conventions to DOMEvent interactions with Promises?

[Tim Guan-tin Chien]

Hi,

I've been looking into Service Worker spec and documentation. I
couldn't help but notice many of the method implemented on the
DOMEvents takes Promise instance as argument(s). For example,

https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/respondWith
https://developer.mozilla.org/en-US/docs/Web/API/ExtendableEvent/waitUntil

I remember at the beginning of the B2G project we have used
event.preventDefault() & event.detail.unblock() for a similar purpose.
See:

https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementParent.js#380-390

I wonder if the pattern of Service Worker is widely accepted and we
should be aiming that design when designing new APIs? Or this is an
issue remain to be settled?

Thanks,


Tim

[Eric Shepherd (Sheppy)]

As I understand it, promises are the new-fashioned way to do this. But my word isn't necessarily all that helpful. But it's how we understand things on the writing team.

Eric Shepherd
Senior Technical Writer
Mozilla

_______________________________________________
dev-webapi mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapi

[Martin Thomson]

On Wed, Apr 1, 2015 at 7:26 PM, Tim Guan-tin Chien <timd...@mozilla.com> wrote:
>
> I wonder if the pattern of Service Worker is widely accepted and we
> should be aiming that design when designing new APIs? Or this is an
> issue remain to be settled?

I believe that this aspect (waitUntil/respondWith) is fairly stable.

There is nothing significantly wrong with

e.putOnHold();
doStuff().then(() => e.takeOffHold());

But this is more concise and arguably better contained:

e.holdUntil(doStuff());

You can't resolve a promise twice, after all.

[Chris Mills]

But you can have a listener that sits there and runs the logic whenever it’s needed. This kind of stuff is mainly why we have waitUntil, in my understanding, to allow some kind of install/uninstall/messaging functionality to happen async:

https://developer.mozilla.org/en-US/docs/Web/API/ExtendableEvent/waitUntil#Example
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers#Updating_your_service_worker
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers#Install_and_activate.3A_populating_your_cache

Seems to be useful for a wide variety of general purposes.

[Benjamin Kelly]

Note, waitUntil() may be extended to the other ServiceWorker events as
well. For example, to let you keep the worker alive while you async
process an onmessage event:

https://github.com/slightlyoff/ServiceWorker/issues/669

Its not spec'd or implemented yet, though.

Ben

[Martin Thomson]

On Thu, Apr 2, 2015 at 6:40 AM, Benjamin Kelly <bke...@mozilla.com> wrote:
> Note, waitUntil() may be extended to the other ServiceWorker events as well.
> For example, to let you keep the worker alive while you async process an
> onmessage event:
>
> https://github.com/slightlyoff/ServiceWorker/issues/669
>
> Its not spec'd or implemented yet, though.

We're using for the push API already.

http://w3c.github.io/push-api/index.html#the-push-event

I believe that we need it for the other event too, but that hasn't be
edited in yet.

[Jonas Sicking]

On Wed, Apr 1, 2015 at 7:26 PM, Tim Guan-tin Chien <timd...@mozilla.com> wrote:
> I wonder if the pattern of Service Worker is widely accepted and we
> should be aiming that design when designing new APIs? Or this is an
> issue remain to be settled?

The way that the JS language is going currently is definitely to use
Promises as way of sending asynchronous results and asynchronous
signals in JS APIs in general. So yes, right now I'd say it's how we
should aim to design API.

Of course, there's no way to tell that this will remain forever.
There's certainly fashions in API design. But the use of promises for
asynchronousness has very nice network effects and so my guess is that
it's something that'll stick.

/ Jonas