DEV Community

Cover image for How to use Axios with React

How to use Axios with React

Femi Akinyemi on August 19, 2022

Introduction Axios is a promise-based HTTP Client for node.js and the browser. Thus, it works equally well in front-end JavaScript appli...
Collapse
 
sfleroy profile image
Leroy

I was wondering why react devs keep using axiom. We have the fetch api and that works just fine and is a really modern way of doing things. When not doing things like serverside js, there's no need for it, is there?

Collapse
 
femi_akinyemi profile image
Femi Akinyemi

In his article entitled "Why JavaScript Developers Should Prefer Axios Over Fetch" betterprogramming.pub/why-javascri... Sabesan Sathananthan discussed the advantages of Axios over Fetch.

 
metammodern profile image
Buniamin Shabanov • Edited

with a lot of numbers in the middle

By 0->100 I didn't mean that it goes straight to 100, I meant that this 0->100 process is happening after the file is already downloaded and response provided.

Here's a sandbox, check yourself (I didn't edit your code, only injected some debug points and comments) codesandbox.io/s/fake-progress-tra...

This is of course, about download response. The upload case is different, but we can use Streams API for that as well I suppose (It's now considered non-experimental, at least Eglish MDN tells so, updated in February 2023(

comes with the language

fetch api is part of browser API, not part of language:)

File API

What does the File API even have to do with requests?

outdated browser API

syncronous XHR is depreciated, asyncronous XHR is still on point and works fine. I'm not planning to support depreciated browsers, I just use the right tool for the job.

Regarding redaxios: I searched through source code and there's no such thing as onUploadProgress declared anywhere:) meaning, it's not fully replacable.

 
metammodern profile image
Buniamin Shabanov

The code snippet you provided doesn't track upload progress, neither it tracks download progress. It only imitates the progress after fetch finishes execution (.then).

Regarding useQuery: it's just a caching and wrapping tool for providing comfortable interface, it doesn't have a data fetching mechanism in it built in. I'm planning to use axios + useQuery in new project.

I'm also not a big fan of using redundant libraries, I stick to fetch when it's possible, but axios gives a bunch of useful stuff, like interceptors, instances, configs etc.

 
metammodern profile image
Buniamin Shabanov • Edited

Example is good, thank you
But this then means that server has to support chunked response.
Regarding File API: Sorry but it doesn't apply to my case, I send the files to server, by "files not leaving browser tab" I meant that they are not getting downloaded to users machine. Of course I wouldn't make fetch requests if there was no server.

And again, I'm not a fanboy which I told before, I was pro-fetch for last couple of years(almost following youmightnotneed.com/), but it's just easier to stick with whatever market suggests.

Anyway, the code you wrote is good, but it requires additional maintenance and changes when new feature is required(meaning, some other handling probably). And as we found out, it requires proper server setup with chunking responses.
I think you could make a quality article out of this thread :) I'd like to see side by side comparison of all the axios features that dev would implement and compare it's bundle size to axios size. Cheers!

Thread Thread
 
femi_akinyemi profile image
Femi Akinyemi

Yes! This thread provides valuable insights that could be compiled into a quality article.

 
metammodern profile image
Buniamin Shabanov

to get the total size of the file to download

Nope, by the time you check content-length and create a stream you've already downloaded the file, the network request was done and was fulfilled by that time, you can put a debugger line and see the Network tab of devtools to see that. Not only that, in your code snippet you only check content-length of the downloaded file, your code doesn't cover the case when user uploads a file himself and expects a file in response, both of those files can be huge, so unless the request is finished you will show 0% to user and then 0->100% by just reading stream of response. That's bad UX.

you shouldn't care about the percentage

  1. You don't know what business case I'm dealing with and what design solutions I implement. I can't tell PM or Designers "oh you shouldn't care about percentage, nobody needs it", it just doesn't work like that.
  2. You can't cover all business use cases with the code snippet you provided.
  3. I'm not talking about file download, that's a different use case and that is indeed covered by browser itself. I'm talking about a case where the uploaded and downloaded files are not leaving the browser tab. I can't give you any popular example from top of my head but you can check convert.leiapix.com and see how it works. It uploads a file and in response expects a depth map file. Those two files are not leaving browser tab and are not downloaded to users storage. Using fetch would not work well here if you want to show upload+download progress. That's why it uses XHR. But using axios would have been much more delightful and easy cause you don't have to support axios and cover it with tests to make sure it works as it's supposed to.
Thread Thread
 
metammodern profile image
Buniamin Shabanov • Edited

whatever you use is built on top of fetch

By the way, axios is built on top of XHR, not fetch:)

 
metammodern profile image
Buniamin Shabanov

The only excuse in my case is having percentage loading indication in UI. Fetch API can't do it. You can do it using XHR, but good luck supporting that frankenstein in your codebase instead of relying on something that is being used by thousands of projects and that is being tested and supported by people who are into it.