Re: Indexed DB + Promises

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