Re: [whatwg] Notifications: making requestPermission() return a promise

On Oct 7, 2014 11:32 PM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
>
> On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:
> > On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:
> >> On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
> >> <domenic@domenicdenicola.com> wrote:
> >>> So we should make a choice, as to whether we want developers to
assume they will always get permission (in which case it should reject upon
permission not being granted), or whether we want developers to ask the API
whether they were granted permission (in which case it should give back a
boolean fulfillment value or similar).
> >>
> >> How can they assume permission is always granted? It's up the user.
> >> It's a request from the developer and the user can say no. What's
> >> unclear about the name?
> >
> > Yeah, you misunderstood the question.  It's about whether permission
> > failure should reject the promise or accept it with a boolean.
>
> Domenic did not ask a question. I asked a question since it's unclear
> to me why a developer could reasonably assume they will always get
> permission.

You're missing context or something.

The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together and
get a nice combined promise that fulfills when everything succeeds, or
write a nice straight success path that assumes permission, and then handle
any errors, including denied permission, at the end, rather than
interleaving error-handling logic into the middle of your code.

~TJ

Received on Wednesday, 8 October 2014 07:52:14 UTC