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:jsb...@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
