Fix: 204 No Content bug

[dzwiedziu-nkg]

Fix of "Unexpected end of JSON input" when HTTP response is 204 No Content

[devvmh]

Hey, this is great, thanks!

This won't work for clients who aren't using the default json format. We need to generalize this so it handles all of the default formats (arrayBuffer, blob, formData, json, or text). I'd also need to look through https://developer.mozilla.org/en-US/docs/Web/API/Response to make sure we're not breaking any other fields by mocking the object like this.

I can do some thinking on this and push a change next week, but if you're able to get it done before then I'll happily merge it once it's ready 😄

[devvmh]

I'm assuming you have a good test env set up for this change. I think also that response.json() should return a string (or null), not another function, i.e.:

return { json: () => null }

Could you also do me a favour and see if this code works instead?

[dzwiedziu-nkg]

Yes, it works :)

[devvmh]

Hi @dzwiedziu-nkg , this is great, but it still needs to be more closely reflecting an actual response object. This change could have unintended consequences to consumers of the library that are looking for keys like text() or formData() on the response.

I'm not sure what the best solution is. If I get the chance to do more thinking on it I'll post something up, but otherwise are you able to make this more closely match the existing api?

[devvmh]

for example, someone might be manually checking the text() value of the response if the status is 204 (this is something I've done before). That would then fail if we pushed this change

[tryangul]

How about something more like

   // fix of "Unexpected end of JSON input" when HTTP response is 204 No Content
    if (response.status === 204) {
      return {
        ...response,
        [format]: () => null,
      };
    }

This way we're not losing any methods

[devvmh]

@dzwiedziu-nkg have you gotten a chance to look at this PR again?