- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 29 Sep 2015 15:12:18 -0700
- To: Domenic Denicola <d@domenic.me>
- Cc: Joshua Bell <jsbell@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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
Received on Tuesday, 29 September 2015 22:13:21 UTC