-
Notifications
You must be signed in to change notification settings - Fork 23
Description
Currently, if I use KakapoResponse and pass status code as 400 for eg, the promise doesn't resolve, it gets rejected.
In my app, I use the rejection to show 'Internet not available' messages, and assume that it will get accepted in all other cases. In the accept case I check response.ok to figure out 400s, etc. This is the behaviour of window.fetch too, as per MDN:
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
The Promise returned from fetch() won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, it will resolve normally (with ok status set to false), and it will only reject on network failure or if anything prevented the request from completing.
I suggest the behaviour should be more like MDN, by doing 2 things
- add an
optionsobject to KakapoResponse like this:
KakapoResponse(code, body, headers, options)
When creating the fakeResponse in fetchInterceptor, this can then be passed on to window.Response, and this way, we can mock actual statusText. Also, status codes should be passed on in the same place, from response.code, EG:
new window.Response(body, { headers: request.headers, status: request.code ...options });
Here's a PR for the same #143
- I suggest not rejecting the promise response.error is true (like is the case for KakapoResponse currently). this might be a breaking change tho, and is debatable, but for testing actual behaviour, I feel like this is necessary.