Re: Indexed DB + Promises

<<
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.
>>

I meant user configurable, maybe as a global config.

On Mon, Sep 28, 2015 at 1:12 PM, Marc Fawzi <marc.fawzi@gmail.com> wrote:

> 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
>>>
>>>
>>
>