I am writing some TypeScript classes that fetch resources by their reference - everyday things like if the resource is a file, the reference is the pathname; if the resource is a web service, the reference is the URL, etc.
In this world, references and resources are always strings.
So I have some code like this:
/**
* Calls an HTTP endpoint
*/
export default class CallEndpoint {
getResource(reference: string): string {
return fetch(reference);
}
}
I want to define getResource
as string
, but eagle-eyed readers know I can't: fetch()
is async, so getResource
can't be defined as returning a string.
I've tried to do some research on this question, and the answer is "properly work with asynchrony as shown in the duplicates linked", which I feel does not answer my question, and brings me to a dead end.
My editor is TypeScript-aware and shows there is an error with the above code. If I do this, it is happy:
export default class CallEndpoint {
async getResource(reference: string) {
return await fetch(reference);
}
}
However, now I am not happy, since I want this to be explicitly marked as returning a string. Indeed, I have written a generic cache wrapper, which I make use of in a child class (CallEndpointCached
) and my interface requires this method to return a string (because, well, a resource is always a string). Do I have to make do with this being essentially untyped?
In other words, is there a way I can block in this function, so that I can obtain a string result that respects the function return type I have chosen?
Update
I suppose the async/await is pointless here, but my editor says it still can't be typed. I think it should be:
export default class CallEndpoint {
getResource(reference: string) {
return fetch(reference);
}
}
Something can await this downstream, I guess.
Footnote
(I've bumped into Promises and async several times, and unfortunately I struggle to fully understand them every time. While I am aware of the performance benefits of async, the stall on developer productivity strikes me as more than sapping those benefits, especially where the system is not in need of optimisation).