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

RE: Indexed DB + Promises

From: Domenic Denicola <d@domenic.me>
Date: Tue, 29 Sep 2015 17:51:24 +0000
To: Joshua Bell <jsbell@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <CY1PR0501MB1369E2B307A0D4A3AA301A9ADF4E0@CY1PR0501MB1369.namprd05.prod.outlook.com>
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
- The two-stage error paths (exceptions + rejections), necessitating async/await to make it palatable
- 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 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? From that perspective, the addition of waitUntil or a similar primitive to allow better control over transaction lifecycle is crucial, since it will enable better wrapper libraries. But the .promise and .complete properties end up feeling like halfway measures, compared to the usability gains a wrapper can achieve. Maybe they are still worthwhile though, despite their flaws. You probably have a better sense of what authors have been asking for here than I do.

Minor usability suggestions:

- Maybe tx.waitUntil could return tx.complete? That would shorten the incrementSlowly example a bit.
- .promise is a pretty generic name. For operations, .ready or .complete or .done might be nicer. (Although nothing sticks out as perfect.) For cursors, I'd suggest something like .next or .nextReady or similar.

From: Joshua Bell [mailto:jsbell@google.com] 
Sent: Monday, September 28, 2015 13:44
To: public-webapps@w3.org
Subject: Indexed DB + Promises

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 Tuesday, 29 September 2015 17:51:58 UTC

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