> 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
