Fetching from API in react

[MahmoudGEA2005]

Select Topic Area

Question

Body

so to fetch from an API in react we can either use the useEffect(), or a combination of useEffect() and useCallback(), but there is a very annoying problem that I see most of the time where we get requests duplication, even though StrictMode was already remvoed from main.tsx, then you start creating refereneces with useRef() to check if the data is stale and decide when to make the request again, especially when we have states that get intiailaized with null then becomes 0

so I learned about the useQuery from TanStack, basically it is used when you want to avoid unneccery fetches like when you switch tabs , but it turned out that it sovles the whole fetches duplication issue with minimal code, so is it considered more professional to use it for API fetches everywhere, like in an AddProduct.tsx component ?

[WalkedPlate]

Yeah, TanStack Query is basically the go-to for data fetching in React nowadays. You're not wrong. Managing fetches manually with useEffect + useRef flags to prevent duplicates gets messy fast.

Using useQuery everywhere for reads and useMutation for things like your AddProduct.tsx (POST requests) is totally fine and pretty standard in production apps. It's not overkill, it's just the right tool for the job.

The only thing I'd add: it's still worth understanding why the duplication happens with raw useEffect (Strict Mode double-mounting, missing cleanup, dependency issues), so you're not just hiding problems behind a library. But once you get that, there's no reason to keep fighting those issues manually when TanStack Query handles it all for you.

[pratikrath126]

Hi MahmoudGEA2005, TanStack Query is definitely the recommended approach for data fetching in React. It handles deduplication, caching, and background updates out of the box. For your AddProduct component, use useMutation for the POST request. Wrap your app with QueryClientProvider at the root. This is considered professional and is widely used in production. The duplication issue you experienced with useEffect is common, and TanStack Query solves it cleanly. Good luck!

[esat54]

Is TanStack Query the Professional Standard for API Fetching in React?

Short answer: yes, and you've already figured out the hard way why it exists. Let me break this down properly.

---

The Root of the Duplication Problem

Before jumping straight to TanStack Query, it's worth understanding what's actually going on under the hood when you fetch with raw useEffect, because this matters.

The duplication you're seeing isn't always StrictMode's fault (though StrictMode does intentionally double-invoke effects in development to surface bugs). The real culprits are usually:

1. Missing cleanup functions

useEffect(() => {
  fetchProducts().then(data => setProducts(data)); // no cleanup
}, []);

If the component unmounts before the request finishes, the state update still fires, causing either a memory leak warning or a stale update on a re-mounted component.

2. Dependency array issues

useEffect(() => {
  fetchProducts(filters);
}, [filters]); // if filters is an object, this fires on every render

Objects and arrays in dependency arrays are compared by reference, not value. So if filters is recreated on each render (which it often is), you get a new request on every single render cycle.

3. The null → 0 state transition you mentioned This one catches a lot of people. When a state initializes as null and then gets set to 0, your effect sees a change in dependency and fires again. You end up writing logic like:

const hasFetched = useRef(false);
useEffect(() => {

if (hasFetched.current) return;

hasFetched.current = true;

fetchData();

}, [someState]);

And now you've got manual cache management, which is exactly what you shouldn't be doing by hand.

---

What TanStack Query Actually Solves

TanStack Query isn't just a "prevent duplicate requests" tool. It's a full async state manager. Here's what it handles that you'd otherwise implement manually:

• Request deduplication — if the same query key is used in multiple components simultaneously, only one request fires
• Caching — results are stored and reused until stale, so switching tabs doesn't refetch unless you want it to
• Background refetching — data silently refreshes when the window regains focus or the network reconnects
• Loading / error states — isLoading, isError, error, data are all managed for you
• Race condition handling — it tracks which response belongs to which request, so stale responses don't overwrite fresh ones

---

Using It in an AddProduct.tsx Component

This is a good example to look at because AddProduct involves a mutation (POST), not a query (GET). TanStack Query has useMutation specifically for this:

import { useMutation, useQueryClient } from '@tanstack/react-query';
const AddProduct = () => {

const queryClient = useQueryClient();
const { mutate, isPending, isError, error } = useMutation({

mutationFn: (newProduct) => axios.post('/api/products', newProduct),

onSuccess: () => {

// Invalidate the products list so it refetches with the new item

queryClient.invalidateQueries({ queryKey: ['products'] });

},

});
const handleSubmit = (formData) => {

mutate(formData);

};
return (

// your form JSX

);

};

Notice queryClient.invalidateQueries — this is one of the cleanest patterns in TanStack Query. When your mutation succeeds, you simply tell the client "this cached data is now stale", and any component currently subscribed to that query key will automatically refetch. No prop drilling, no global state updates, no manual array splicing.

---

Should You Use It Everywhere?

Pretty much, yes — with one nuance.

For any server state (data that lives on a backend and needs to be fetched, cached, or synchronized), TanStack Query is the right call. This covers the majority of API interactions in a real app.

What it's not for is client state — things like form input values, UI toggles, modal open/close state. That's still the domain of useState, useReducer, or Zustand/Redux depending on complexity.

A clean mental model:

Type	Tool
Server data (GET)	useQuery
Server mutations (POST/PUT/DELETE)	useMutation
UI / local state	useState / useReducer
Complex shared client state	Zustand, Redux, Jotai

---

Setup (if you haven't already)

// main.tsx
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
const queryClient = new QueryClient();
ReactDOM.createRoot(document.getElementById('root')!).render(

<QueryClientProvider client={queryClient}>

<App />

</QueryClientProvider>

);

You can also install the devtools during development — they give you a live view of every query, its cache status, and how many observers are subscribed to it:

npm install @tanstack/react-query-devtools

import { ReactQueryDevtools } from '@tanstack/react-query-devtools';
// inside QueryClientProvider

<ReactQueryDevtools initialIsOpen={false} />

---

Final Take

The fact that you went through the useEffect + useRef pain before reaching TanStack Query actually puts you in a better spot than most. You understand why the problem exists, not just that the library fixes it. That makes you significantly better at debugging edge cases when they inevitably come up, even inside TanStack Query.

Is it professional to use TanStack Query for API fetches across the board? It's more than professional — at this point, not using it (or something equivalent like SWR) in a production React app is what raises eyebrows.