How about awaiting Arrays ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Sat Mar 4 17:15:35 UTC 2017


glad this topic moved some interest, but I'd like to share my opinion about
locking down to `Promise.all` only any possible solution, as example:

> I don't believe .race to be common use case (especially when we consider
it's edge case with empty array).

As mentioned already, `fetch` API is a clear case where you want to fetch
races, if not actually fetching any in case the resource wasn't present in
the local cache.

Fetch API has this funny little gotcha that erase somehow unpredictably and
Promise.any would solve many things there, granting that at least, instead
of an error, the user donwloaded the last online version of that resource
and tried to store it again.

Race on NodeJS side plays also very well when you have an pool of n odes
pointing at different DB instances, all synchronized and happy, all capable
of falling back to other nodes.

Race in these cases is a way more common use case.

Promise.all is actually useful for list of tasks to wait for, like loading
modules asynchronously, but for all cases where the full list ain't needed,
it makes the program slow for no reason.

I know you all know these things but then again, I use race and any quite
often and reading "not a common use case" didn't match reality here.

Last, but not least, `await.all` and friends looks even better proposal
than `[].all` to me, specially because it's not related to Arrays and it
can work with any iterable.

It's also future friendly for `.race` and `.any` too :party-emoji:

Best Regards














On Sat, Mar 4, 2017 at 3:03 PM, Matthew Robb <matthewwrobb at gmail.com> wrote:

> Honestly Isiah my largest motivation for thinking this is worth solving
> boils down to the fact that async/await does a good job of hiding the
> promise and generator based implementation under it but this falls down so
> fast when adding Promise.all.
>
> I'm helping a new person learn JavaScript right now and he's using fetch
> to get some JSON. Explaining the first then returning res.json() and the
> second one chaining as well as 'this' considerations was a disaster. He
> conceptually understands asynchronous code so when I backed up and did the
> same thing with async/await he just got it. Saving him from needing to
> learn anything about promises until later on.
>
> In my opinion if a layer of sugar doesn't fully abstract the layers it
> sits upon then it's an incomplete and confusing feature. I'd go so far as
> to say that async/await should always support every capability of promise
> without anyone touching Promise directly.
>
> On Mar 3, 2017 9:12 PM, "Isiah Meadows" <isiahmeadows at gmail.com> wrote:
>
>> First, I'll start out with this: I tend to be very adverse to new syntax,
>> but I'll draw exceptions for things that enable whole new ways of looking
>> at and manipulating code, like async functions and decorators, or things
>> that enable new functionality altogether, like `function.sent` or private
>> class fields. Things that haven't hit that bar for me include the bind
>> syntax proposal (beyond function pipelining) and the
>> `await.all`/`await.race` idea here.
>>
>> BTW, I had some ideas on unifying that with observables at the syntax
>> level here, particularly with my `parallel` and `await parallel` ideas
>> there: https://github.com/tc39/proposal-observable/issues/141
>>
>> Basically, it unifies the common case of merging promises and observables
>> with a fairly low syntactic footprint.
>>
>> As for `Promise.race`, I see it much less frequently, and it's much
>> simpler and faster under the hood to implement due to less state needed, so
>> I didn't see the need to add support for that.
>>
>>
>> -----
>>
>> Isiah Meadows
>> me at isiahmeadows.com
>>
>> On Fri, Mar 3, 2017 at 11:59 AM, Michał Wadas <michalwadas at gmail.com>
>> wrote:
>>
>>> My mistake Array.from is not necessary because Promise.all accepts any
>>> iterable.
>>>
>>> Though I don't believe .race to be common use case (especially when we
>>> consider it's edge case with empty array).
>>>
>>> Hsving parity with spread and rest parameters seems consistent for me.
>>>
>>> On 3 Mar 2017 17:54, "T.J. Crowder" <tj.crowder at farsightsoftware.com>
>>> wrote:
>>>
>>>> On Fri, Mar 3, 2017 at 4:51 PM, Michał Wadas <michalwadas at gmail.com>
>>>> wrote:
>>>> > Actually I would go with
>>>> >
>>>> > await ...expr;
>>>> >
>>>> > As sugar for:
>>>> >
>>>> > await Promise.all(Array.from(expr))
>>>>
>>>> Which is great for `Promise.all`, but leaves us without `race` or
>>>> things that may be added in future (like Andrea's `any`). (Granted `all`
>>>> has to be the dominant use case...)
>>>>
>>>> Why the `Array.from` part of that?
>>>>
>>>> -- T.J.
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170304/48ce4cd3/attachment-0001.html>


More information about the es-discuss mailing list