Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make fetchInterceptor + KakapoResponse behaviour more like actual fetch implementation #144

Open
palashkaria opened this issue Jan 19, 2018 · 0 comments

Comments

@palashkaria
Copy link

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

  1. 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

  1. 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant