- From: Marc Fawzi <marc.fawzi@gmail.com>
- Date: Mon, 28 Sep 2015 13:12:03 -0700
- To: Joshua Bell <jsbell@google.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <CACioZit=_+JdiQDEGT2Ce4sB4WFundbkqs0jpYByL95SUDmyHA@mail.gmail.com>
Yes, sorry. <<As the syntax additions are "just sugar" on top of Promises, the underlying issue of mixing IDB+Promises remains. >> That's for implementors such as yourself to work through, I had assumed. I just went over the Readme from the perspective of an IDB user. Here is some potentially very naive feedback but i it s so obvious I can't help but state it: 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. This way the syntax is not polluted with .promise everywhere and there would be no chance of forgetting to add .promise or intentionally mixing the bare IDB API with the promise returning version in the same code base which can be very confusing .... I apologize if this makes no sense. I am a fan of IDB and had used is successfully in the past without the Promise stuff. It takes some getting used to but the IDB API is powerful AS IS and if you're going to make it more approachable while keeping its row power I would probably skip ES5/Promise (in terms of usage examples) and focus on async/await usage because as you state under Concerns: - Methods that return requests still throw rather than reject on invalid input, so you must still use try/catch blocks. Fortunately, with ES2016 async/await syntax, asynchronous errors can also be handled by try/catch blocks. Also, I think with the scenario of potentially infinite wait (waitUntil(new Promise())) the only thing I can think of is a timeout that is configurable on waitUntil, e.g. waitUntil(new Promise()).maxTime(30s) On Mon, Sep 28, 2015 at 12:36 PM, Joshua Bell <jsbell@google.com> wrote: > On Mon, Sep 28, 2015 at 11:42 AM, Marc Fawzi <marc.fawzi@gmail.com> wrote: > >> Have you looked at ES7 async/await? I find that pattern makes both simple >> as well as very complex (even dynamic) async coordination much easier to >> deal with than Promise API. I mean from a developer perspective. >> >> > The linked proposal contains examples written in both "legacy" syntax > (marked "ES2015") and in ES7 syntax with async/await (marked "ES2016"). > Please do read it. > > As the syntax additions are "just sugar" on top of Promises, the > underlying issue of mixing IDB+Promises remains. The proposal attempts to > make code using IDB with async/await syntax approachable, while not > entirely replacing the existing API. > > >> >> Sent from my iPhone >> >> On Sep 28, 2015, at 10:43 AM, Joshua Bell <jsbell@google.com> wrote: >> >> 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 Monday, 28 September 2015 20:13:11 UTC