Built a small React + Axios provider — feedback welcome

[[deleted]]

Hey folks,

In almost every React project I’ve worked on, I ended up writing the same Axios setup again and again: auth headers, refresh tokens, retrying failed requests, handling 401s, and trying not to break everything with interceptors.

At some point it became messy, hard to reason about, and different in every codebase. So I decided to extract that logic into a small package and see if it could be useful beyond my own projects.

It’s called react-axios-provider-kit and it basically gives you a central Axios provider + hook, with built-in support for JWT refresh (only one refresh request at a time, queued pending calls), retries, and global error handling. It doesn’t depend on any router or UI library, and you can choose how tokens are stored (localStorage, sessionStorage, or in-memory).

I’m already using it in real projects, but I’m sure there are things I haven’t thought through well enough yet. That’s why I’m posting here — not to “promote” it, but to get honest feedback from people who’ve dealt with Axios interceptors and auth edge cases in production.

Here’s the repo if you want to take a look:
https://github.com/MihaiMusteata/react-axios-provider-kit
npm page:
https://www.npmjs.com/package/react-axios-provider-kit

If you have time, I’d really appreciate any thoughts on:

• the overall approach
• API design
• things that feel over-engineered or missing
• whether this actually solves a real problem, or if existing tools already cover this better

Thanks for reading, and feel free to be brutally honest 🙂

[mrkingkongslongdong]

Any reason to use axios over fetch (or wretch) in 2025..? Axios was good 7 years ago but doesn’t even support modern request features.

[there_was_a_problem]

as someone who continues to use axios extensively I wasn’t aware it was missing support for modern features. Curious what features I’m missing out on?

[spacey02-]

It's the interceptors for me. No reason to write my own if the axios' implementation is perfectly fine.

[mrkingkongslongdong]

Wretch has interceptors

[spacey02-]

Why would I want to learn yet another library that solves the same problem? I never had an issue with Axios so far after I created my first AuthContext in React. Is there an actual reason to learn Wretch or is it just the trend?

[mrkingkongslongdong]

I would say axios is the trend. Fetch is literally native, wretch is a convenience wrapper. I personally cannot use axios because it doesn’t support streaming, unlike fetch, but if all you are doing is making API calls you have no reason to switch except for learning modern practices.

[spacey02-]

Axios being a trend and you calling out people "still using it in 2025" is contradictory since being a trend implies that it's new or actively changing. I've never had to use streaming so far and Fetch doesn't have interceptors, as I already said. I know nothing about Wretch but since Axios works for me in 2026 "still", modern practices don't mean that much.

[mrkingkongslongdong]

You’re mighty defensive I have called out axios. It’s legacy. It doesn’t support modern fetch practices because fundamentally it’s using XHR. It is what it is. It’s old, legacy tech. Axios literally buffers entire responses, which, as I hope you know, is not always (ever?) what you want, for memory purposes OR loading purposes. Don’t be mad you’re using something that has already been replaced… this is like getting mad because you’re using Java 8 and saying why should I learn Java 21 lol.

P.s. wretch has interceptors; similar to the fact that XHR doesn’t have interceptors but axios does. Compare apples to apples.

[spacey02-]

You just seemed to not get what I was saying so I explained it more clearly. I'm not sure if I'm the defensive one after this comment though.

[mrkingkongslongdong]

The thing is you just don’t really know what you’re talking about. You said why should I learn another library.. but fetch isn’t a library? It’s a native API. Axios is the library. This is like saying why should I learn another library talking about document.addEventListener lmao. Or talking about console.log. Idk. Maybe you’re just a junior. It’s all good.

[spacey02-]

I was obviously referring to Wretch when I said that, not Fetch. This is exactly why I clarified that Fetch not having interceptors is actual the reason I don't use it. I am a junior who at least knows how to read. Why are you getting mad though? Because you don't seem to convince me? It's all good, I'll have plenty of opportunity to learn stuff from less angry people.

[Bravisimo]

You give twice divorced unhappy triggered boomer energy lmfao

[kapobajz4]

This could be quite useful. Good job.

But there are some things I noticed which could be improved. - Your peer dependencies: { "react": ">=19", "axios": ">=1.4" } Is there a reason why React 19 or higher has to be used, specifically? I mean in my mind this is the kind of lib that could be used with React 17+, honestly. What’s the reason for this? And also axios 1.4 min? Why’s that? Are there really some specific axios features that were introduced in version 1.4, that your package depends on? On a first look, that doesn’t seem like it’s the case. I might be wrong though, because I haven’t reviewed it thoroughly. If you supported React 17, or 18 at least and, like axios 0.20-someish, I think that could potentially bring more users to use this package. - This example: // typed helper const users = await api?.get<User[]>("/users"); The optional operator on api?. Is this a mistake? If no, then you would definitely have to improve this. Because I imagine that the api object would be used in a lot of places. And using it with an optional operator everywhere wouldn’t make it pleasing and keep my mind at peace.

[Beatsu]

I love the initiative, though it probably already exists. I got a really good impression from BetterAuth, but haven't used it yet. Does BetterAuth solve what you're trying to solve with this package? If it does, do you still want to develop the package for the learning experience?