Re: Indexed DB + Promises

[Marc Fawzi]

Yes, sorry.

<>

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  wrote:

> On Mon, Sep 28, 2015 at 11:42 AM, Marc Fawzi  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  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
>>
>>
>

Re: Indexed DB + Promises

[Joshua Bell]

On Mon, Sep 28, 2015 at 11:42 AM, Marc Fawzi  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  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
>
>

Re: Indexed DB + Promises

[Marc Fawzi]

<<
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.

On Mon, Sep 28, 2015 at 1:12 PM, Marc Fawzi  wrote:

> Yes, sorry.
>
> < 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  wrote:
>
>> On Mon, Sep 28, 2015 at 11:42 AM, Marc Fawzi 
>> 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  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
>>>
>>>
>>
>

Re: Indexed DB + Promises

[Marc Fawzi]

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. 


Sent from my iPhone

> On Sep 28, 2015, at 10:43 AM, Joshua Bell  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
> 

Indexed DB + Promises

[Joshua Bell]

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

Re: Indexed DB + Promises

[David Rajchenbach-Teller]

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



signature.asc
Description: OpenPGP digital signature

Re: Indexed DB + Promises

[Marc Fawzi]

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> 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
>
>

RE: Indexed DB + Promises

[Aaron Powell]

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 
Cc: Joshua Bell ; 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 
> 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

Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

[Ryosuke Niwa]

Hi,

Attending the recent meeting for shadow DOM styling [1] convinced me to join 
CSS WG, and further that we need a joint meeting between CSS WG and WebApps WG 
on this topic during TPAC to iron out the details.

Can we have a joint meeting (of one or two hours) on Monday (10/26) or Tuesday 
(10/27) for this?

[1] https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting

- R. Niwa