Re: Promises in async methods

On Tue, Oct 04, 2016 at 04:05:08PM +0200, Sebastian Noack wrote:
>Since I wasn't there, I'd like to follow up here. We (Adblock Plus) would
>love to see a browser extension API that natively supports promises, though
>as long as some supported browsers still expect callbacks it wouldn't make
>anything easier for us. But it seems that the Chromium team is also
>considering using promises:
>https://bugs.chromium.org/p/chromium/issues/detail?id=328932

My understanding is that promise support is a very low priority 
for the Chrome team, and they don't intend to implement it any 
time soon. However, I'm currently working on a lightweight 
polyfill library that should allow extensions written to work 
with promises in the `browser` namespace to work consistently in 
Chrome and browsers that target our spec.

>As for compatibility with the existing Chrome extension API, I think that
>won't be an issue. We could just have methods take an optional callback and
>return also promise. IMO this would make more sense than a separate
>namespace or a new manifest option/version.

That's the approach that Firefox currently takes for the 
`browser` namespace, but we're likely to move to only supporting 
promises in that namespace if that's what winds up in the spec. 
I think that for the sake of simplicity and consistency, that's 
the approach that makes the most sense.

>However, the only problem I see, is that some methods, currently do some
>internal optimizations if the callback is omitted, e.g. if you send a
>message and there is no callback for the response, Chrome immediately
>closes the internal port. Those kind of optimizations would be impossible
>if a promise is returned, which might or might not be used later. Though
>I'm not sure how significant those optimizations are, and if necessary, I
>guess, we could still keep using callbacks for the few APIs where it makes
>sense for performance reasons, while using promises for most methods.

Firefox implements the callback-based versions of these APIs as 
thing wrappers around the promise-based implementation, so our 
internals don't behave any differently when optional callbacks 
are omitted. This hasn't caused any noticeable performance 
impact for us, so far.

>Also, I'd like to point out, that in addition to have async methods return
>a promise, it would be great if message responders could deal with
>promises, so that instead of:
>
>  browser.runtime.onMessage.addListener(function(message, sendResponse)
>  {
>    if (message == "get-foo")
>    {
>       browser.storage.local.get("foo", function(items)
>       {
>         sendResponse(items.foo);
>       });
>       return true;
>    }
>    return false;
>  });
>
>One could write:
>
>  browser.runtime.onMessage.addListener(function(message)
>  {
>    if (message == "get-foo")
>    {
>       return browser.storage.local.get("foo").then(items => items.foo);
>    }
>  });

As it happens, this is exactly how it currently works in Firefox 
:)

-- 
Kris Maglione
Firefox Add-ons Engineer
Mozilla Corporation

Received on Wednesday, 5 October 2016 19:46:58 UTC