Managing server data with TanStack Query

Fetching data often starts with a straightforward request. An interface needs a list of items, so I load it from an API and display the result.

The work around that request tends to grow. I need to show a loading state, handle a failed response and refresh the list after an edit. If another component needs the same data, I also need to decide where to keep it.

TanStack Query gives those concerns a consistent place. It manages fetching, caching and updating server data, reducing the amount of coordination I need to write myself.

Keeping the request straightforward

TanStack Query does not replace the function that makes the request. I can still use fetch or an existing API client. A query connects that function to a key identifying its data.

For a list of projects, that key might be ['projects']. Components using the same key share the cached result through the same query client. The query also exposes the request state, so the interface can respond while data is loading or when something goes wrong.

What I find useful is having a consistent approach across screens. Each component still decides what to display, but it does not need its own version of the same request bookkeeping.

Refreshing after a change

Loading a list is only part of the job. After saving an edit, the interface needs to reflect what changed.

TanStack Query lets me invalidate the relevant queries. This marks their cached data as stale and, by default, refreshes queries currently being used. After updating a project, I can invalidate the projects query instead of manually coordinating a reload between components.

I still need to decide which data an action affects. The library handles the refresh, but that relationship remains part of the application.

Defaults still need attention

Caching also means deciding when data should be refreshed. By default, TanStack Query considers cached data stale and can refetch it when a component mounts, the browser window regains focus or the connection returns.

Those defaults are worth understanding. A list that changes frequently may need different settings from reference data that stays the same throughout the day.

For me, the value is having fewer scattered decisions around each request. I still decide which fields are required before saving a project and which lists need refreshing afterwards, but there is less repetitive work around each request.