Skip to content

Promise.all is not resolve type promise in intellisense #8492

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Thaina opened this issue May 6, 2016 · 8 comments
Closed

Promise.all is not resolve type promise in intellisense #8492

Thaina opened this issue May 6, 2016 · 8 comments
Assignees

Comments

@Thaina
Copy link

Thaina commented May 6, 2016

Promise.all should be able to take array of Promise<T> and resolve array of T

But it not work as expect

image

As you can see pairs should be number[]
Which cause from a problem in this file

image

So I fix it like this

image

image

@mhegazy
Copy link
Contributor

mhegazy commented May 6, 2016

@sandersn can you take a look.

@sandersn
Copy link
Member

sandersn commented May 13, 2016

@Thaina, I can't repro your fix. In fact, it seems like the problem arises from the constructor call, so I don't see how changing the type of all will help inference to PromiseConstructor.new.

The root cause is that the compiler can't do whole-program type inference, so it can't use the call resolve(1) to figure out that the Promise is a Promise<number>.

The reason that the compiler infers {} for T in new Promise((resolve, reject) => { resolve(1) }) is that type inference comes only from arguments -- (resolve, reject) => { resolve(1) } in this case. But this function argument is contextually typed, so it tries to get type for its parameters from the function it was called from (new Promise).

So when the compiler requests the contextual type of resolve, it sees that it's (value?: T | PromiseLike<T>) => void. It detects the type variable T, and since it's contextually typed, knows that it has no chance to infer it. So it sets T={} and continues.

@sandersn sandersn added the Design Limitation Constraints of the existing architecture prevent this from being fixed label May 13, 2016
@Thaina
Copy link
Author

Thaina commented May 14, 2016

@sandersn That's not my point

I mean even that Promise.all not return Promise<number[]> it should return Promise<any[]> And when I call then(pairs) pairs should be number[] or at least any[]

But it turn out that Promise.all return Promise<Promise<{}>[]> so pairs is Promise<{}>

What I suspect is, PromiseLike<T> is not Promise<T> so I fix it and that work. pairs just become any[]

@DanielRosenwasser
Copy link
Member

The cause of this is discussed at #5254.

I mean even that Promise.all not return Promise<number[]> it should return Promise<any[]>

I'm curious as to why you think so. Can you elaborate?

@Thaina
Copy link
Author

Thaina commented May 14, 2016

@DanielRosenwasser No it's not related in anyway. I only talk about Promise.all not a constructor of Promise. Just look at the Promise.all().then in my screenshot and you would see that the type of parameter named pairs is Promise which should not. It could be anything but Promise

@sandersn
Copy link
Member

I think I understand a bit better, but now I can't repro the problem. I typed in almost exactly the code from your screenshot:

Promise.all([new Promise((resolve, reject) => { resolve(2) })])
       .then(pairs => pairs[0]);

The type of pairs is {}[] for me, not PromiseLike<{}>[]. I tried this from master and the playground (1.8.x). What version of TypeScript are you using?

Note that {}[] is still a useless type, but at least it's not still wrapped in a Promise. Based on the limitation I described above, you'll need a type parameter annotation on new Promise<number> to get the correct type:

Promise.all([new Promise<number>((resolve, reject) => { resolve(2) })])
       .then(pairs => pairs[0]);

Now pairs: number[].

@sandersn sandersn removed the Design Limitation Constraints of the existing architecture prevent this from being fixed label May 16, 2016
@mhegazy mhegazy closed this as completed May 16, 2016
@sandersn
Copy link
Member

This is a dupe of #7566. #7566 is fixed in 2.0. I'm not sure why it works in the playground.

@sandersn
Copy link
Member

Never mind, I pasted in my own definition of Promise to the playground since it doesn't support ES6.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants