misleading or missing documentation, must JSON.stringify body

[davekaro]

I tried to follow the doc example to patch to my rails server:

const response = await patch('localhost:3000/my_endpoint', { body: { name: 'Request.JS' }})

but noticed that [object Object] was being sent as the body. Looking at samples on https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch, I updated my code to stringify the JSON payload first.

const response = await patch('localhost:3000/my_endpoint', { body: JSON.stringify({ name: 'Request.JS' })})

Is this expected or did I miss something? Should the library do this for us? Maybe when the detected content type is application/json (

request.js/src/fetch_request.js

Line 73 in 0eda429

return 'application/json'

) it should stringify the body?

[marcelolx]

@davekaro Well, I think the docs are wrong. I didn't pay attention to this detail when I wrote the docs, will fix them soon as possible.

About the idea of request.js doing this, I'm not sure if we should or not do it, but maybe if we detect the content-type is application/json and the body is a js object we stringify the body, if it is already a string we do nothing. 🤔 Anyway, I'll fix the docs while I think in this possibility

[davekaro]

Thanks! Yeah I can see if this is a lightweight wrapper for fetch, it would be better to keep it that way and expect folks to rely on how fetch works.

[marcelolx]

@davekaro I've fixed the docs. I agree with your point but I think that if we can provide the possibility to the user send the body of the request in both ways and document this, it can be be useful. At least I think that it is a bit anoying to need to stringify the body every time I'll do such kind of request.

I'll close the issue, since the docs match the behavior but I will work on supporting this functionality and then we can see what the other folks think about