Joshua Bell worked on a simplified API using IndexedDB and promises:
This suffers from race conditions because of the code mitigating the locking which is an issue. I have not had much time to look at this however it strikes me this can be resolved by transactions being queued before being resolved in the promise. So long as all transactions come from the same instance then the issue should not be an issue here.
By implementing a stack of transactions that are called FIFO ordering the API of IndexedDB removes the need to manage state from the outside.
As Joshua has stated this was just a thought exercise implementing schemas and indexing would also be important I feel.
Ugh, let’s not dwell on that silly “SimpleDB” thing :(. Truly just a thought experiment about minimal async storage so that other things could be built upon it. Given that the first commentary above is that it needs transactions, schemas, and indexes, it shows that IndexedDB’s feature set is not, in fact, too much. It’s the UX of the API that needs help. And unfortunately the current API ties the transaction model to the event loop very tightly - see IDB+Promises for the gruesome details.
More realistic thoughts on evolving IDB include:
Having requests and transactions expose promises to observe lifetimes - in IDB+Promises
Allowing transactions to “wait” on promises to compose larger operations - also in: IDB+Promises
“transactionless” operations - I need to write this up/prollyfill it, but basically allow read/write requests that get an implicit transaction that commits immediately. These could just yield promises.
I think those would provide the basis to experimentally evolve the API to be easier to use and compose better with other Promise-based code flows. They wouldn’t necessarily make it easier on their own, but without more explicit control over transaction lifetimes you can’t do much to improve the API in JS and create Promise-based cowpaths to pave.
I think the explicit commit control is a great idea. I also wonder if we could kill two birds with one stone and solve the issue of promises/callbacks within transactions at the same time.
If you could open an IDB transaction while explicitly saying “hey, I want to control the commit,” then there’s no need for fancy Promise fixes because the transaction can just patiently wait until you commit(). An added benefit is that this would also work for non-promise async APIs that you might want to access inside of a transaction, such as FileReader or XHR.