[0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
Apparently you need to use some special object type. Why doesn't the universal key/value type work for passing a key/values? Who knows – maybe there's a good reason, maybe not. I do know that sending [object Object] is literally never what anyone could possibly want and that almost any other design choice would be less idiotic.
So I just use xmlHttpRequest or jQuery.ajax(). xmlHttpRequest is kind of awkward, but it's straight-forward and you don't get nonsense like this.
I also don't care much for promises, and fetch is pretty promise-heavy.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
This is the worst of dynamic languages: if you mess something up and you get an error: okay, fair. If you mess something up and you ignore it or do something insane: that's just stupid.
"Read the documentation from cover to cover to something as simple as sending a HTTP request" isn't really much of solution.
> The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null.
The standard data type for POST is form data, so it could just default to that for objects.
Or it could throw an error.
Sending [object Object] is not reasonable behaviour in any shape or form. I guess it just calls the JS "to string" logic ("logic"), but spreading that to new APIs is just not a good design, especially when it's "hidden".
Because there isn't one?
By "itself" (i.e. <form> tags without JS), the browser can POST using two different encoding formats: - Url encoding (similar to what you'd see in the URI, but as the body of the request) - multipart/form-data (a derivative of MIME, needed for file uploads)
What's it supposed to do if you passed an object containing a CryptoKey instance, a Blob and a ReadadbleStream??
We also have a ton more ways of encoding and sending data in a POST (which is just the HTTP method, it doesn't convey anything bar that there's probably a body and related headers attached we want the server to do something with).
JSON, XML, CSV, YAML to name but a few key/value formats.
Hell, maybe it's an S3 style endpoint and you just push the raw bytes to save.
fetch is... less "magic" by default. This makes it flexible, but means you have to put just a tiny bit of effort into it.
Or... just use Axios, I ain't your manager; I get by easily enough with a helper js that gets treeshaked out so that I can just call `postJSON(url, body, opts=null)`
> Or... just use Axios, I ain't your manager; I get by easily enough with a helper js that gets treeshaked out so that I can just call `postJSON(url, body, opts=null)`
The fact that everyone "just" has to use a wrapper for a basic system API is exactly the problem, especially when this was supposed to be the new shiny thing that would replace the old cruft. Why do I have to add 4 dependencies + 44 "dev dependencies" just to make a HTTP request?
Plus, for my personal projects I want to avoid the "npm ecosystem", and I especially want to avoid any JS build system.
Because form data (and the FormData object which is what you’re expected to use) is often not a map (in the sense of key -> value) but rather a set of entries (as in, still a key-value container, but the same key might be present multiple times). They definitely could have supported a POJO but I personally like this bit of type strictness (and it’s easily abstracted away if you prefer, in whatever way you prefer).
https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...