it's not about when it throws, it's how it handles errors. It hides the response in error.response.data, which becomes a big issue when dealing with typescript.
And I just don't like writing error.response?.data?.whatever in general. I generally prefer dealing with Response.
And there's no way to conditionally tell axios to not parse responses. One big reason to not use axios is because of the all or nothing behaviour. You have build a client for each scenario (which is unrealistic)
You can type axios, example: await axios.post<EventType[] | { errorMessage: string }>(urlApiCmdPublic, cmd)
so I would not count that as a downside. Fetch in comparison does not have any types at all.
"no way to conditionally tell axios to not parse responses" - that's a fair point,
but its relevant only if using some non-http/rest APIs - which to be fair should be pretty rare.
I agree with you, that axios is mostly designed to consume http/rest apis with good developer experience
and having the niche use-case of calling lower level binary apis is best served using lower level tools like fetch.
await axios.post<EventType[] | { errorMessage: string }>(urlApiCmdPublic, cmd) only works for non-error responses.
Fetch in comparison does not have any types at all
Not exactly true, you get aResponse which makes sense. And then you can convert to json and do validation i.e using zod schema.parse(await response.json()) to get a concrete type. Which is a much better approach than what axios offers
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One reason to avoid axios, difficult to handle errors.
How is it more difficult to handle than fetch?
You can even overwrite/define then it throws errors
pipedream.com/community/t/faq-how-...
it's not about when it throws, it's how it handles errors. It hides the response in error.response.data, which becomes a big issue when dealing with typescript.
How is accessing the response with
error.response.datain typescript a big problem?When using
asyn/awaityou loose all types, so you have to doAnd I just don't like writing
error.response?.data?.whateverin general. I generally prefer dealing withResponse.And there's no way to conditionally tell axios to not parse responses. One big reason to not use axios is because of the all or nothing behaviour. You have build a client for each scenario (which is unrealistic)
You can type axios, example:
await axios.post<EventType[] | { errorMessage: string }>(urlApiCmdPublic, cmd)so I would not count that as a downside. Fetch in comparison does not have any types at all.
"no way to conditionally tell axios to not parse responses" - that's a fair point,
but its relevant only if using some non-http/rest APIs - which to be fair should be pretty rare.
I agree with you, that
axiosis mostly designed to consume http/rest apis with good developer experienceand having the niche use-case of calling lower level binary apis is best served using lower level tools like
fetch.await axios.post<EventType[] | { errorMessage: string }>(urlApiCmdPublic, cmd)only works for non-error responses.Not exactly true, you get a
Responsewhich makes sense. And then you can convert to json and do validation i.e using zodschema.parse(await response.json())to get a concrete type. Which is a much better approach than what axios offers