Re: Indexed DB + Promises

On Mon, Oct 5, 2015 at 3:27 PM, Joshua Bell <jsbell@google.com> wrote:

> Thanks for all the feedback so far. I've captured concrete suggestions in
> the issue tracker -
> https://github.com/inexorabletash/indexeddb-promises/issues
>
>
>
> On Wed, Sep 30, 2015 at 11:10 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>
>> On Wed, Sep 30, 2015 at 11:07 AM, Kyle Huey <me@kylehuey.com> wrote:
>> > On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>> >> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <d@domenic.me>
>> wrote:
>> >>> I guess part of the question is, does this add enough value, or will
>> authors still prefer wrapper libraries, which can afford to throw away
>> backward compatibility in order to avoid these ergonomic problems? From
>> that perspective, the addition of waitUntil or a similar primitive to allow
>> better control over transaction lifecycle is crucial, since it will enable
>> better wrapper libraries. But the .promise and .complete properties end up
>> feeling like halfway measures, compared to the usability gains a wrapper
>> can achieve. Maybe they are still worthwhile though, despite their flaws.
>> You probably have a better sense of what authors have been asking for here
>> than I do.
>> >>
>> >> Remember that the *entire point* of IDB was to provide a "low-level"
>> >> set of functionality, and then to add a sugar layer on top once
>> >> authors had explored the space a bit and shown what would be most
>> >> useful.
>> >>
>> >> I'd prefer we kept with that approach, and defined a consistent,
>> >> easy-to-use sugar layer that's just built with IDB primitives
>> >> underneath, rather than trying to upgrade the IDB primitives into more
>> >> usable forms that end up being inconsistent or difficult to use.
>> >
>> > At a bare minimum we need to actually specify how transaction
>> > lifetimes interact with tasks, microtasks, etc.  Especially since the
>> > behavior differs between Gecko and Blink (or did, the last time I
>> > checked).
>>
>
> Yeah - "When control is returned to the event loop" isn't precise enough.
> It's an open issue in the 2nd Ed. and I welcome suggestions for tightening
> it up. Note that Jake Archibald, at least, was happy with the Blink
> behavior, after chewing on it for a bit. But it still seems far too subtle
> to me, and someone who writes blog posts explaining tasks vs. microtasks is
> probably not the average consumer of the API. :)
>
>
>> >
>> > waitUntil() alone is a pretty large change to IDB semantics. Somebody
>> > mentioned earlier that you can get this behavior today which is true,
>> > but it requires you to continually issue "keep-alive" read requests to
>> > the transaction, so it's fairly obvious you aren't using it as
>> > intended.
>>
>> Yeah, any necessary extensions to the underlying "bare" IDB semantics
>> that need to be made to support the sugar layer are of course
>> appropriate; they indicate an impedance mismatch that we need to
>> address for usability.
>>
>
> Agreed.  So... I'm looking for additional feedback that the proposal
> addresses this mismatch, with both waitUntil() on transactions (kudos to
> Alex Russell) and the promise accessors on transactions/requests and minor
> cursor tweaks which difficult to get correct today.
>
>
Dusting this off. Any additional feedback? If we gain implementation
experience and handle the details tracked at
https://github.com/inexorabletash/indexeddb-promises/issues does this
approach seem like viable path forward for other implementers?