Skip to content

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

@palashkaria

Description

@palashkaria

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions