React: Performing API calls with Tanstack

An revised approach to working with APIs

Today I am going to discuss my preerred approach towards performing REST calls in React. There is a lot of content on this topic, and I did not necessarily want to add to the pile, however I have seen various approaches online, as well as on projects that I don't consider optimal. To illustrate my point, let's take a look at a very basic example.

1
2  const [isLoading, setIsLoading] = useState(true);
3	const [isError, setIsError] = useState(false);
4	const [data, setData] = useState(null);
5
6	useState(
7		()=>{
8
9			fetch('/api/endpoint')
10			.then(data=>{
11				data.json();
12			})
13			.then(json=>{
14				setIsLoading(false);
15				setData(json);
16			})
17			catch(e)
18				console.warn(e);
19				setIsError(true);
20		},
21		[]
22
23	);
24

So a vanilla approach, get's the job done, however there are a few areas for improvement. First of all, the loading status, error status, and data are explicitly managed. Each component definition perorming calls needs to perform this action. The variable names are also subject to variation as different developers may have a tendency to name their variables differently across the application.

Next, the actual call is tightly bound to the component. I personally prefer a level of abstraction when it comes to interacting with remote servers. Basically this means separating the low level details into a separate class. Imagine an requirement where an auth token is sent in the heads. Given the above approach, we would need to add this logic into every low level fetch API call, which becomes a bit repetative, and in the event that token changes, puts us in a position where we would need to make these changes all over the application, vs in a centralized location.

Finally, any caching needs to be manually rolled by hand, which further adds to the complexity. There are numerous apporoaches to caching, and you might find yourself actually on a project where different strategies are implemented.

Introducing TankStack useQuery

The useQuery library is a powerfull option for working with remote API calls. It offers fetching and caching options in an almost effortless manner. Data remains cached when between between components. Exception handling is built in. Refreshing of data may be configured at an specified intervals where they run in the background. Paralell and dependent queries are also supported. These are a few of the core features, but not inclusive of all of the available options.

Let's take a look at a revised version of fetching data using the Tanstack approach.

1
2  const { data, isLoading, error } = useQuery('todos', fetchTodos); 
3

First we will notice that the state (loading, loaded, and error) as well as the reference to the payload are no longer manually declared. These variables are autowired in via the hook. You will also notice that the variables used to represent state default to a given naming convention. This helps to enforce a standardized naming convention, however these names may be optionally overridden.

The first argument provided is the query key, or unique identifier for the operation. In this example, pretty straightforward, however the signature accepts additional values for the key which enables more granular tuning over the fetch behavior.

The second argment is a reference to a separate method which performs the actual fetch operation. All remote calls have been abstracted to a single centralized location, streamlining the logic, and providing support for future enhancements.

Upon the first instantiation of the component, an asynch call is made to perform the fetch operation. Subsequent calls will inherit the cached data. You will notice that in this case, the logic is executed in a single line, without the additional need for wiring the call into a hook.

Now let's perform the operation with a defined time after which the data is considered expired. Here we establish a compound query key where caching is applied for a specified subset of the products, and an explicit 10 second period before the data expires is set. For instances where you are working with data that seldom changes, which is often the case or feeds that drive drop down menus, this is a great opportunity to optimize inteaction with the API via caching. While it is true, if the API returns information in the headers which indicate a timeperiod after which the data is considered stale, which the fetch API will honor, I honestly seldom see these headers correctly returned by the client, so you are better off controlling it from the browser. Alternatively, we can replace the staleTime attribute with the refetchInterval property, which will poll and refetch data in the background.

1
2  useQuery({ queryKey: ['products','books], fetchProducts('books') staleTime: 10000 }); 
3

So far these examples perform a simple query operation, after which the data is set into the data variable (should the call succeed). Should we need to add in logic for whatever reason upon then the data is returned, we can provide a callback function as follows.

1
2  useQuery({ queryKey: ['products','books], queryFn: ()=>{ ... } staleTime: 10000 }); 
3

Application State

I have seen a number of examples where data is retrieved and then stored into application state, for the most part with Redux. This approach becomes interesting as data is cached at a global level. So stashing the data in Redux becomes somewhat redundant as we already have the results, which will be persisted across component navigation operations.

In Summary

So we have touched on my preference for React based APIs interactions. I would summarize my approach as including the following.

Actual API interactions isolated into centralized, reusable files, not within the component.
The useQuery method serves as a wrapper to server interactions.
Utilization of the bult in caching behavior vs. storing in a Redux store.

I have found this approach to be a consisten, low effort approach towards working with APIs, and would really recommend anyone to take a look at this approach and adopt it if it is a good it.

Top