🌸 A elegant way to consume API's at front-end
Tags: webdev, javascript, frontend, api
Published: 2023-04-07 23:00:18

## Pros and cons / when to use the react-query library.

### What is react-query and what pain point does it solve?

What is react-query and what pain point does it solve? Even though the library has changed its name (to TanStack Query), we will still refer to it as react-query here, ok?

On the library's website, it is described as: "The missing data fetching library for React apps, but in more technical terms, it makes it very easy to fetch, cache, synchronize and update server state in your React apps."

We can interpret this as: "I am a library that helps you fetch data more efficiently using my own hooks, store that data in cache for better performance, create a more reliable loading screen. In addition, I make the code more readable and easier to handle."


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fqawc5mtrznj087gz3lw.png)



### What other way is there to do this?

If you have used React in a project, you have probably come across the following syntax:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v9prw05xn421ffb8c9ci.png)

#### Explaining the code would be:
Importing axios and creating an auxiliary state for each functionality (error, data, and loading...) :


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nyav20t5zbzfk02cop4c.png)

Using useEffect to call our function to hit the API and bring this data to set in our data State every time the component (or screen) is loaded.

But first, we set our two error and loading states to give the impression that it is "loading..." and that "there is no error", which is a lie because what is happening is "I haven't hit the API yet, I don't know what's going on there."

This way, the first thing your function does is not to hit the API but to set the various states.

I recommend reading "Why useEffect is a bad place to make API calls": https://articles.wesionary.team/why-useeffect-is-a-bad-place-to-make-api-calls-98a606735c1c.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pcf0m7txl8swcv87fpgb.png)

and finally consume this data and states in our JSX return statement:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0680cpa69sqc9v5gm3qz.png)

Although it may not be entirely accurate, this logic still works! And if your app doesn't have a large number of users and requests, I believe this code will serve its purpose without major issues.

## What pain does React-Query solve?

Error handling: React Query provides an integrated way to handle server request errors. This can help you easily deal with common error scenarios, such as network failures and server errors.
With this, goodbye setIsError and its derivatives. Now, controlling error and loading states with React Query's own hooks has become much better:

We can also create a folder called "hooks" and fill it with hooks for each endpoint or API request. With this, we don't necessarily need this inelegant useEffect body with a new function call in each component/screen.

Simplified code: React Query can help simplify your code by reducing the amount of boilerplate code you need to write to handle server responses.

👉🏽 And the key differential of the library, for me, is:

### Cache:

 React Query's cache layer can help improve application performance by reducing the number of network requests needed to retrieve data. This can improve the responsiveness of the application and reduce server load a lot.

Optimistic updates: React Query allows you to update the cache with optimistic updates, which means you can update the user interface before waiting for the server response. This can make your application seem faster and more responsive.

##When not to use it?
As great as the library may be, it's important to be cautious about over-engineering.

### Learning curve:

 React Query has its own API and it can take some time to learn how to use it effectively. It is also necessary to understand the underlying concepts of the library, such as cache, invalidation, and so on.

### Not always necessary: 

For smaller applications, it may not be necessary to use React Query. The cache and error handling features may not be as useful in small-scale applications where performance is not a major concern.

### Integration with existing code: 

If you are adding React Query to an existing codebase, you may need to refactor your existing code to work with the library. This can be time-consuming and increase the overall complexity of your code.

### Overhead: 

Like any library, React Query has overhead in terms of package size and performance. For small applications, this overhead may not be justified.

# Final considerations
This article does not intend to teach you how to use react-query, but you can follow the step-by-step guide in the documentation:
https://tanstack.com/query/v4/docs/react/installation

Or if you need a video, we have Fernanda Kipper:
https://www.youtube.com/watch?v=ZI9uLACYAd0

Or a more specific one about cache:
https://www.youtube.com/watch?v=YmS5uo9ty2Q


---


Hope this post can be helpful!
For some feedback or more content, follow me on [twitter](https://twitter.com/daniellimae) or [github](https://github.com/bolodissenoura)