Re: Indexed DB + Promises

One of the things I like about the WebSQL API is that the transaction
aborts if any queries fail or if any callbacks throw errors. This way the
whole transaction can be handled as a promise easily, which provides nice
abstraction to the calling code.

It comes at the expense of each individual operation being promisified,
each operation still takes a callback so that you know for sure when code
is 'done' handling a result (it's hard to tell when a promise is done
because .then can be called multiple times and at any time).

I would like to see any work on IndexedDb promises go the same way:

1. Figure out how to tell if a transaction succeeded or failed.
2. Wrap the transaction in a promise, so that code can be structured at a
high level with promises.
3. (Optional) represent each request as a promise, if that's compatible
with goal 1.

If I remember rightly it's hard to do 1 in general with the current
non-promise based API, so any change to make the  API more promise
based should first address that.

Conrad




On Tuesday, September 29, 2015, Jake Archibald <jaffathecake@gmail.com>
wrote:

> I agree with Jonas, I'd like to see IDBRequest and IDBTransaction be
> thenables. This could be done by having a hidden promise, and having
> .then/.catch proxy to the same methods on the hidden promise.
>
> We just have to get over the throw/reject thing.
>
> On Tue, 29 Sep 2015, 23:16 Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <d@domenic.me
>> <javascript:_e(%7B%7D,'cvml','d@domenic.me');>> wrote:
>> > This seems ... reasonable, and quite possibly the best we can do. It
>> has a several notable rough edges:
>> >
>> > - The need to remember to use .promise, instead of just having
>> functions whose return values you can await directly
>>
>> One way that we could solve this would be to make IDBRequest a
>> thenable. I.e. put a .then() function directly on IDBRequest.
>>
>> > - The two-stage error paths (exceptions + rejections), necessitating
>> async/await to make it palatable
>>
>> I'd be curious to know if, in the case of IDB, this is a problem in
>> practice. I do agree that it's good for promise based APIs to only
>> have one error path, but IDB is pretty conservative about when it
>> throws.
>>
>> Do people actually wrap their IDB calls in try/catch today?
>>
>> Certainly throwing at all isn't perfect, but is it a big enough
>> problem that it warrants using a library?
>>
>> > - The waitUntil/IIAFE pattern in the incrementSlowly example, instead
>> of a more natural `const t = await openTransaction(); try { await
>> useTransaction(t); } finally { t.close(); }` structure
>>
>> I'm actually quite concerned about using a t.close() pattern. It seems
>> to make it very easy to end up with minor bugs which totally hang an
>> application because a transaction is left open.
>>
>> But maybe developers prefer it strongly enough that they'll use a
>> library which provides it.
>>
>> > I guess part of the question is, does this add enough value, or will
>> authors still prefer wrapper libraries, which can afford to throw away
>> backward compatibility in order to avoid these ergonomic problems?
>>
>> Yeah, I think this is a very good question. I personally have no idea.
>>
>> / Jonas
>>
>>