Hi Jake 👋🏽
A quirk I ran into today:
Promise.reject, if passed a promise object as an argument won’t wait for that promise the way
Promise.resolve does. At first, this seemed like a bug, so I checked out the spec, it was quite clear—that pseudo-pseudo-code is super readable for us mere mortals, isn’t it? ISN’T IT?—that the behaviour between these two functions is different.
This post assumes you’re familiar with the
fetch API. If not, here’s some refresher:
- The call to
fetchreturns a promise with two possible paths: a response (success) and an error. Both objects that get passed to these respective callbacks have similar API (interface)
- Both the success and error objects have functions defined to parse the body into text, or json, or binary blobs. The
json()function returns a promise that resolves to the parsed JSON output, or an error if the parsing fails.
The problem can be better explained with the comparison between the two following code snippets:
Now, from what I understand, this is in line with the spec, where there is a difference between the definition of
I’m not entirely sure about why this design decision exists. My initial guess was that the semantics become a bit weird because if you called
x.json() resolved, should that value be force-rejected?
Anyhow, this force-reject functionality can be achieved by an explicit function:
And use this in place of
Promise.reject in the earlier case: