Learning TanStack Query - History, Background & Why You Need It

#Introduction

Every great library is born from pain. TanStack Query is no exception: it was born because a generation of React developers had to rewrite the same code — fetch, loading, error, then re-render — in every single component. Before you understand how to use it, it is important to know why this library exists and what problems it solves.

Episode 1 traces the evolution of data fetching in React, from the painful manual pattern to an automatic cache system. You will also understand the key concept that justifies this library's existence: server state and how it differs from client state.

#The Evolution of Data Fetching in React

#The useEffect and Manual Fetch Era

In the early days of React, almost every application fetched data the same way: calling fetch inside useEffect, storing the result in useState, and managing loading and error manually:

The tiring manual pattern

function Profile({ userId }) {
  const [user, setUser] = useState(null)
  const [loading, setLoading] = useState(true)
 
  useEffect(() => {
    setLoading(true)
    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => {
        setUser(data)
        setLoading(false)
      })
  }, [userId])
 
  if (loading) return <p>Memuat...</p>
  return <h1>{user.name}</h1>
}

The problem isn't just the number of lines. This pattern has no cache, no deduplication, no consistent error handling, and no way to re-sync stale data. Every component that needs the same user has to fetch it again.

#The Birth of react-query

In 2019, Tanner Linsley released react-query. The idea was simple but revolutionary: don't store server data in component state, but in a global cache managed by the library. Components simply declare what data they need, and the library handles fetching, caching, and updates.

#The Rebrand to TanStack Query

As more frameworks gained support, react-query was renamed to TanStack Query and reorganized into the TanStack monorepo. The TanStack name reflects its new mission: not just a React library, but a family of data-fetching libraries for many frameworks. Version v5 was released in 2023 and has been continuously updated through 2026 with improvements and new features.

#The Problems TanStack Query Solves

#Server State Differs from Client State

The key to understanding lies in the term server state. Data that comes from the server — lists of users, posts, account balances — has characteristics that local state like input text or scroll position doesn't have:

• Data can change on the server side without the application knowing.
• Data can be used by many components at once.
• Fetching data requires the network, so there is latency and the possibility of failure.

That is why mimicking local storage for server data is the wrong approach. TanStack Query treats server data as a cache: stored, given an expiration time, and re-synced when needed.

#Automatic Features Provided by the Library

Everything that used to be done manually is now automatic:

• Caching: data is stored in the cache and can be read again instantly.
• Deduplication: identical requests are merged into a single fetch.
• Background refetch: data is refreshed in the background when the window regains focus or the connection returns.
• Retry: failed requests are retried with a delay.
• Invalidation: specific queries are marked stale and refetched.

As a result, loading and error boilerplate shrinks dramatically, and synchronizing state between components no longer needs to be managed manually.

#Small Size and a Framework-Agnostic Core

TanStack Query is very lightweight — about 13 KB (gzipped) for the React binding — and the core logic lives in the @tanstack/query-core package, which is independent of any framework. The React, Vue, and Svelte adapters are just thin layers on top of the same core.

@tanstack/query-core → caching logic (framework-agnostic)
       ↓
@tanstack/react-query → hooks for React
@tanstack/vue-query   → composables for Vue
@tanstack/solid-query → primitives for Solid

The @tanstack/query-core → @tanstack/react-query diagram illustrates the dependency flow: all adapters use the same core, so the knowledge you gain from React also applies to other frameworks — episode 19 will discuss this.

#TanStack Query vs Other Approaches

Before closing this episode, it is important to know that TanStack Query isn't the only solution. There is SWR from Vercel, RTK Query from the Redux ecosystem, Apollo Client for GraphQL, and of course manual fetch as a baseline. Each has a different philosophy: SWR focuses on staleness and being lightweight, RTK Query integrates tightly with Redux Toolkit, and Apollo handles complex GraphQL caching.

An in-depth comparison and a guide on when to choose each will be fully discussed in episode 22. For now, remember: TanStack Query excels at flexibility, finely configurable caching, and a broad ecosystem of adapters.

#Closing

Episode 1 laid out the philosophical reason for TanStack Query's existence: server data is a cache, not local state. You now understand the journey from the manual useEffect plus fetch pattern, the birth of react-query in 2019, the rebrand to TanStack Query, and the server state problems it tries to solve.

Key takeaways:

• Manual data fetching with useEffect is repetitive and full of boilerplate.
• react-query was born in 2019 by Tanner Linsley, then rebranded to TanStack Query.
• Server state differs from client state and needs cache treatment.
• Caching, deduplication, background refetch, and retry are provided automatically.
• The core library is framework-agnostic at about 13 KB gzipped.
• TanStack Query isn't the only solution; full comparison in episode 22.

In the next episode, episode 2, we will discuss the core concepts and key architecture of TanStack Query — the query versus mutation model, how query keys work toward the cache, and the main components such as QueryClient and QueryClientProvider. This is the mental foundation you will use in every episode that follows.