... to support more fine-grained commenting and collaboration.
-
-
Save inexorabletash/8c122c84a65de65c35b3 to your computer and use it in GitHub Desktop.
I still think I'd like IDBRequest
and IDBTransaction
to have then
and catch
methods that proxy to an underlying promise. Seems like forgetting to add .promise
is going to be common.
@domenic I guess this idea makes you sick in your mouth?
Thanks, @jakearchibald !
Promise properties should vend the same promise each time. So
tx.promise === tx.promise
.
Fixed in the "roughly equivalent to" example. Already present in the polyfill and normative text.
Guess this should be
await tx.promise;
Yes, I missed a few of those. Bleah. Added 'em in.
I think I prefer
.complete
, but earlier you call it.promise
.
I'd switched over but forgot when I made some edits. Corrected - it's .complete
everywhere.
Unfortunately they can throw errors, which would violate http://www.w3.org/2001/tag/doc/promises-guide#always-return-promises if they returned promises
Bleah, good catch. Will ponder.
One option for IDBCursor's advance()/continue() would be to have them return an IDBRequest which then has .promise
hanging off of it. The question is: what IDBRequest? Those methods currently reset the readyState of the original IDBRequest used to open the cursor from "done" back to "pending" and fire off new "success" or "error" events.
How about
cursor()
andadvance()
return the same IDBRequest originally used to open the cursor (NOTE: I've wanted this in other polyfills!)- Generate a new internal, unfulfilled Promise (the one returned by
.promise
) for the request at the same time as the readyState is reset
So rq.promise === rq.promise
would still hold, just not over time. Iteration would then look like:
async function getAll(store, query) {
let result = [];
let cursor = await store.openCursor(query).promise;
while (cursor) {
result.push(cursor.value);
cursor = await cursor.continue().promise; // only change
}
return result;
}
Promise properties should vend the same promise each time. So
tx.promise === tx.promise
.Guess this should be
await tx.promise;
Will this cause the promise returned by
waitUntil
to reject? Hah, just saw your note on this. In ServiceWorkerwaitUntil
returns void. It also throws if the state is invalid.This is really tricky. As a developer, how would I choose a timeout given my code will be running on devices with different cpus etc? Would timeout be a simple timer, or related to transaction inactivity?
I think I prefer
.complete
, but earlier you call it.promise
.Unfortunately they can throw errors, which would violate http://www.w3.org/2001/tag/doc/promises-guide#always-return-promises if they returned promises. The answer here is either willful violation (I imagine @domenic would be against this, and it would be messy in terms of WebIDL), or the cursor returned by
.openCursor().promise
is different to the cursor inidbResult.value
, in that it has some kind of flag set that makes.advance()
return a promise rather than void.FWIW, here's the ES6 version:
Needs
.promise
at the end?