I’ve been maintaining an IDB wrapper using Promises for a few years now[1].
Some things I’ve learnt are: · Sharing transactions are a pain, but can be beneficial · Cursors would lead to a nicer implementation on generators · Async looks like a nicer abstraction on top · Transaction vs Request makes promises challenging I’m going to take a bit more of a look into Joshua’s implementation when I get a few moments as the above is my perspective from my approach so far. [1] http://github.com/aaronpowell/db.js From: Marc Fawzi [mailto:marc.fa...@gmail.com] Sent: Tuesday, 29 September 2015 6:40 AM To: David Rajchenbach-Teller <dtel...@mozilla.com> Cc: Joshua Bell <jsb...@google.com>; public-webapps@w3.org Subject: Re: Indexed DB + Promises How about using ES7 decorators, like so: @idb_promise function () { //some code that uses the IDB API in Promise based way } and it would add .promise to the IDB APIs On Mon, Sep 28, 2015 at 1:26 PM, David Rajchenbach-Teller <dtel...@mozilla.com<mailto:dtel...@mozilla.com>> wrote: On 28/09/15 22:14, Marc Fawzi wrote: > << > Instead of having .promise to appended to the IDB methods as > in `store.openCursor(query).promise` why couldn't you configure the IDB > API to be in Promise returning mode and in that case openCursor(query) > would return a Promise. >>> > > I meant user configurable, maybe as a global config. That sounds problematic. What if a codebase is modernized piecewise, and only some modules have been made Promise-friendly? -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
