Should not reject on 400+ responses

[Ethan-Arrowood]

Great work on this module. One recommendation is that you should not reject on 400+ responses. From discussions throughout other like projects (whatwg/fetch#18) I believe its a common practice to allow the user to decide what happens with their response. The promise should only reject if an actual network error occurs.

Now, this is your library and 100% your opinion so I'm not telling you to change anything; just sharing information you may not have been exposed to.

Good work nonetheless!

[lukeed]

Hey, thank you 🙌

The earliest versions of this didn't reject on 400+. I used it for a bit and tbh I didn't like it. It made testing easy, but I/you inevitably end up adding if blocks or switch statements to react to the status code.

This was far more verbose & annoying in the long run IMO.

I decided to roll with 400+ rejections to follow the HTTP status codea' meaning more closely. Anything above 400 is a non-successful response, which, in userland, translates to an abruption in your "happy path" 99% of the time.

That, to me, almost exactly describes a catch 😄

Sounds reasonable?

[Ethan-Arrowood]

Yes very true. I used to have this exact thought pattern, but when I started working with the fetch api I needed to rewire my thinking to the other way. As long as you have this well documented (which you do) then I think you're good to go 😁

[lukeed]

Awesome, thank you 🙇