W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2015

Re: Indexed DB + Promises

From: Marc Fawzi <marc.fawzi@gmail.com>
Date: Mon, 28 Sep 2015 13:12:03 -0700
Message-ID: <CACioZit=_+JdiQDEGT2Ce4sB4WFundbkqs0jpYByL95SUDmyHA@mail.gmail.com>
To: Joshua Bell <jsbell@google.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Yes, sorry.

<<As the syntax additions are "just sugar" on top of Promises, the
underlying issue of mixing IDB+Promises remains. >>

That's for implementors such as yourself to work through, I had assumed.

I just went over the Readme from the perspective of an IDB user. Here is
some potentially very naive feedback but i it s so obvious I can't help but
state it:

Instead of having .promise to appended to the IDB methods as in
`store.openCursor(query).promise`
why couldn't you configure the IDB API to be in Promise returning mode and
in that case openCursor(query) would return a Promise.

This way the syntax is not polluted with .promise everywhere and there
would be no chance of forgetting to add .promise or intentionally mixing
the bare IDB API with the promise returning version in the same code base
which can be very confusing ....

I apologize if this makes no sense. I am a fan of IDB and had used is
successfully in the past without the Promise stuff. It takes some getting
used to but the IDB API is powerful AS IS and if you're going to make it
more approachable while keeping its row power I would probably skip
ES5/Promise (in terms of usage examples) and focus on async/await usage
because as you state under Concerns:

   -

   Methods that return requests still throw rather than reject on invalid
   input, so you must still use try/catch blocks. Fortunately, with ES2016
   async/await syntax, asynchronous errors can also be handled by try/catch
   blocks.

Also, I think with the scenario of potentially infinite wait (waitUntil(new
Promise())) the only thing I can think of is a timeout that is configurable
on waitUntil, e.g. waitUntil(new Promise()).maxTime(30s)






On Mon, Sep 28, 2015 at 12:36 PM, Joshua Bell <jsbell@google.com> wrote:

> On Mon, Sep 28, 2015 at 11:42 AM, Marc Fawzi <marc.fawzi@gmail.com> wrote:
>
>> Have you looked at ES7 async/await? I find that pattern makes both simple
>> as well as very complex (even dynamic) async coordination much easier to
>> deal with than Promise API. I mean from a developer perspective.
>>
>>
> The linked proposal contains examples written in both "legacy" syntax
> (marked "ES2015") and in ES7 syntax with async/await (marked "ES2016").
> Please do read it.
>
> As the syntax additions are "just sugar" on top of Promises, the
> underlying issue of mixing IDB+Promises remains. The proposal attempts to
> make code using IDB with async/await syntax approachable, while not
> entirely replacing the existing API.
>
>
>>
>> Sent from my iPhone
>>
>> On Sep 28, 2015, at 10:43 AM, Joshua Bell <jsbell@google.com> wrote:
>>
>> One of the top requests[1] we've received for future iterations of
>> Indexed DB is integration with ES Promises. While this initially seems
>> straightforward ("aren't requests just promises?") the devil is in the
>> details - events vs. microtasks, exceptions vs. rejections, automatic
>> commits, etc.
>>
>> After some noodling and some very helpful initial feedback, I've got what
>> I think is a minimal proposal for incrementally evolving (i.e. not
>> replacing) the Indexed DB API with some promise-friendly affordances,
>> written up here:
>>
>> https://github.com/inexorabletash/indexeddb-promises
>>
>> I'd appreciate feedback from the WebApps community either here or in that
>> repo's issue tracker.
>>
>> [1] https://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
>>
>>
>
Received on Monday, 28 September 2015 20:13:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:57 UTC