Skip to content

Suggestion: Allow array of > 10 values in argument of Promise.all() and Promise.race() #22469

Description

@davidjenkins

Currently, Promise.all() and Promise.race() both have signatures like this:

all<T1>(values: [T1 | PromiseLike<T1>]): Promise<[T1]>;
// ...
all<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10>(values: [T1 | PromiseLike<T1>, T2 | PromiseLike<T2>, T3 | PromiseLike<T3>, T4 | PromiseLike <T4>, T5 | PromiseLike<T5>, T6 | PromiseLike<T6>, T7 | PromiseLike<T7>, T8 | PromiseLike<T8>, T9 | PromiseLike<T9>, T10 | PromiseLike<T10>]): Promise<[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10]>;

While this is suitable in most cases, occasionally there is a need (or preference) to wait on the retrieval of several (10+) dependencies and then access them all within a single block.

Workarounds for Promise.all() certainly exist (i.e. splitting into multiple Promise.all() calls) - but code can become unnecessarily complex. Workarounds for Promise.race() are not as easy.

Since actual implementations of Promise.all() and Promise.race() are boundless, it would be helpful if lib.es2015.promise.d.ts reflected a wider range of plausible use cases.

Proposed solution:
Add overloads to lib.es2015.promise.d.ts - using the pattern it already uses today - to support ~20 items instead of ~10.

Activity

  1. dead-claudia commented on Mar 11, 2018

    @dead-claudia

    This is almost a dupe of this as a subset of that bug (and an already-known one).

  2. jack-williams commented on Mar 11, 2018

    @jack-williams
    Collaborator

    @isiahmeadows I feel like I'm being slow...but what does Promise.all look like with variadic generics?

  3. dead-claudia commented on Mar 12, 2018

    @dead-claudia

    It's still a WIP feature (no set-in-stone syntax), but there are a few experimental PRs. There's a couple different concept implementations of Promise.all in that issue.

  4. jack-williams commented on Mar 12, 2018

    @jack-williams
    Collaborator

    @isiahmeadows Cheers. My initial "Ctrl-F" attempts didn't expand into the collapsed comments so I missed function all<...T>(promises: [...Promise<T*>]): T;. I figured the solution might be something like that but I was just scratching my head wondering if there was a way to do it only according the initial spec with ...T.

  5. davidjenkins commented on Mar 12, 2018

    @davidjenkins
    Author

    @isiahmeadows I completely agree, #5453 would appear to completely solve this problem, should it be accepted.

    I should point out though, that while #5453 would be a complete/permanent solution, there is much more consideration that it must be given before being officially rolled out. In the meantime, lib.es2015.promise.d.ts could be extended using the pattern it already uses today - which could be accomplished in minutes - let's say to support ~20 items instead of ~10 - as a short term gap-stop while #5453 goes through the standard process of being reviewed/implemented/released.

  6. typescript-bot commented on Apr 9, 2018

    @typescript-bot
    Contributor

    Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

  7. locked and limited conversation to collaborators on Jul 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DuplicateAn existing issue was already createdFix AvailableA PR has been opened for this issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions