await* would be cool, even if it saves just 10 chars. 2016-10-26 13:14 GMT+02:00 Andrea Giammarchi <[email protected]>:
> > in case of rejecton, other promises don't get cancelled/reverted > > **yet**, since cancelable Promises is something already available in > bluebird and it will eventually land on JS land too (it'd be about the > time, `Promise.all` is indeed yet another use case for cancelability) > > So yeah, `Promise.all` is for optimistic use cases, but I wouldn't call it > a code smell: it's just a pattern. > > ```js > Promise.all([ > waitHourOn12, > waitMinuteOn12, > waitSecondsOn12 > ]).then(dingDong12); > ``` > > Regards > > > On Wed, Oct 26, 2016 at 11:48 AM, Michał Wadas <[email protected]> > wrote: > >> You avoid only few very limited cases of parallelism. >> >> When you use Promise.all you are awaiting either on *all promises to >> resolve or first rejection*, but in case of rejecton, other promises >> don't get cancelled/reverted. That's pattern not present in synchronous >> code. Awaiting on values is more similar to synchronous code. >> Awaiting for all promises can be necessary, but in most use cases it's >> better to start processing already available values as fast as possible. >> Though I appreciate map/filter methods from Array.prototype. >> >> And on topic - await* is probably syntax to go (though I would recommend >> asynchronous iterators proposal). >> And on the margin - it would be nice to have functional >> map/filter/each/reduce on native promises (Bluebird have these and they are >> awesome). >> >> On Wed, Oct 26, 2016 at 12:19 PM, Andrea Giammarchi < >> [email protected]> wrote: >> >>> avoiding parallelism? can you please elaborate a bit more what's the >>> code smell, exactly? >>> >>> On Wed, Oct 26, 2016 at 10:49 AM, Michał Wadas <[email protected]> >>> wrote: >>> >>>> Actually using Promise.all with async/await is usually code smell - >>>> you probably should await on values. >>>> >>>> >>>> >>>> On Wed, Oct 26, 2016 at 10:40 AM, Damian Senn <[email protected]> >>>> wrote: >>>> >>>>> I don't like the `await* []` syntax, it doesn't really tell me what >>>>> it's doing. >>>>> I could imagine something like `await.all []` or `await.race []` >>>>> desugaring to `await Promise.all([])` and `await Promise.race([])`, this >>>>> could also be expanded to whatever new functionality might be added in the >>>>> future (assuming await.something could work). >>>>> >>>>> On Wed, Oct 26, 2016 at 10:37 AM kdex <[email protected]> wrote: >>>>> >>>>>> Personally, I wouldn't mind such an operator, as I feel that the use >>>>>> of `Promise.all` clearly >>>>>> outweighs all other `Promise` combinators, but this could be an >>>>>> opinionated view. >>>>>> >>>>>> IIRC, that even was up for standards discussion at some point (being >>>>>> called `await*` instead >>>>>> of `await`). I'm not sure what ever happened to that. >>>>>> >>>>>> On Wednesday, October 26, 2016 1:27:28 AM CEST Olivier Lalonde wrote: >>>>>> > Right it makes sense, should have thought about that! An `awaitAll` >>>>>> (or >>>>>> > other syntax) could be nice but it seems the general opinion is >>>>>> against. >>>>>> > >>>>>> > On Wed, Oct 26, 2016 at 1:22 AM, kdex <[email protected]> wrote: >>>>>> > >>>>>> > > It's especially beneficial for designing APIs where you don't >>>>>> care about if >>>>>> > > users pass you a `Promise` or the actual data to work with. >>>>>> > > >>>>>> > > Imagine a scenario where you would like to remove a set of files: >>>>>> > > >>>>>> > > ```js >>>>>> > > async function remove(filesArray) { >>>>>> > > const files = await filesArray; >>>>>> > > /* … work with `files` here …*/ >>>>>> > > } >>>>>> > > ``` >>>>>> > > >>>>>> > > In the scenario above, you could pass an array of files, or a >>>>>> `Promise` >>>>>> > > that resolves >>>>>> > > to said array; the function accepts both. >>>>>> > > >>>>>> > > On Wednesday, October 26, 2016 1:03:37 AM CEST Olivier Lalonde >>>>>> wrote: >>>>>> > > > I didn't realize `await` could be used on non-`Promise`s, never >>>>>> mind. I >>>>>> > > > wonder why that is, seems strange. Maybe so that async >>>>>> functions could be >>>>>> > > > more easily swapped out with sync ones in code? I do think >>>>>> `Promise.all` >>>>>> > > > should deserve special treatment because it is so common, unlike >>>>>> > > > Promise.race (who uses that seriously?) and future combinators. >>>>>> But I'm >>>>>> > > not >>>>>> > > > sure it is worth introducing new syntax for. >>>>>> > > > >>>>>> > > > On Wed, Oct 26, 2016 at 12:33 AM, Jordan Harband < >>>>>> [email protected]> >>>>>> > > wrote: >>>>>> > > > >>>>>> > > > > Your suggestion would preclude having a promise for an array >>>>>> (exactly >>>>>> > > what >>>>>> > > > > `Promise.all` returns). >>>>>> > > > > >>>>>> > > > > If you want `await` syntax for `Promise.all`, you'd need >>>>>> different >>>>>> > > syntax >>>>>> > > > > for it - and then, what about `Promise.race`? What about >>>>>> other future >>>>>> > > > > combinators? >>>>>> > > > > >>>>>> > > > > On Wed, Oct 26, 2016 at 12:25 AM, Olivier Lalonde < >>>>>> [email protected]> >>>>>> > > > > wrote: >>>>>> > > > > >>>>>> > > > >> I don't think so, what do you mean? >>>>>> > > > >> >>>>>> > > > >> On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă < >>>>>> > > > >> [email protected]> wrote: >>>>>> > > > >> >>>>>> > > > >>> Then Promise.resolve([p1, p2]) should be like >>>>>> Promise.all([p1, p2]) ? >>>>>> > > > >>> >>>>>> > > > >>> _______________________________________________ >>>>>> > > > >>> es-discuss mailing list >>>>>> > > > >>> [email protected] >>>>>> > > > >>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> > > > >>> >>>>>> > > > >>> >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> -- >>>>>> > > > >> - Oli >>>>>> > > > >> >>>>>> > > > >> Oli Lalonde >>>>>> > > > >> http://www.syskall.com <-- connect with me! >>>>>> > > > >> >>>>>> > > > >> _______________________________________________ >>>>>> > > > >> es-discuss mailing list >>>>>> > > > >> [email protected] >>>>>> > > > >> https://mail.mozilla.org/listinfo/es-discuss >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > >>>>>> > > >>>>>> > > _______________________________________________ >>>>>> > > es-discuss mailing list >>>>>> > > [email protected] >>>>>> > > https://mail.mozilla.org/listinfo/es-discuss >>>>>> > > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
