Re: Indexed DB + Promises

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.