You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 options object 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.
The text was updated successfully, but these errors were encountered:
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
I suggest the behaviour should be more like MDN, by doing 2 things
options
object to KakapoResponse like this:KakapoResponse(code, body, headers, options)
When creating the
fakeResponse
infetchInterceptor
, 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
The text was updated successfully, but these errors were encountered: