Closed
Description
"typescript": "^2.7.2",
"typescript-eslint-parser": "^14.0.0",
If I have promise like this:
export default function to<T>(promise: Promise<T>) {
return promise
.then((data: T) => {
return { error: undefined, data };
})
.catch((error: Error) => {
return { error, data: undefined };
});
}
And after that I add async await with this logic:
public someMethod() {
const { error, data } = await to<SomeType>(SOME PROMISE HERE);
if(error) {
return;
}
// HERE I WILL NOT BE ABLE TO GET SomeType because Typescript still recognise data as type:
// undefined | SomeType
data.
}
Maybe this is some bug with IDE I don't know. I am usigin Visual Code.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
DanielRosenwasser commentedon Jun 17, 2018
TypeScript doesn't have a way to correlate the types of
error
anddata
once you've destructured them into independent variables.Otherwise, being able to discriminate on
undefined
ornull
on a property of an object is an open issue: #24479vforv commentedon Jun 17, 2018
That is bad because I need to hack data variable like this:
(data as Website[])
to make it workkitsonk commentedon Jun 17, 2018
I think @DanielRosenwasser might have looked at it a bit too quickly... What you have written int TypeScript could easily be improved to accomplish your intent:
These sort of basic questions are best asked on StackOverflow or Gitter though.
kitsonk commentedon Jun 17, 2018
Actually, @DanielRosenwasser is right, though I am not entirely sure you wanted/needed what Daniel was suggesting. While it is mildly inconvenient, you can still access the type. Your original code was still flawed though in representing the return of the function. Here is a slightly better example which expresses what Daniel was talking about when run under
--strictNullChecks
:vforv commentedon Jun 18, 2018
Yes, in this part
data should be just string but not string | undefined
typescript-bot commentedon Jul 2, 2018
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.