Dependent Queries in React Query
Learn how to reason about server data that cannot exist independently, and how React Query coordinates those dependencies without turning rendering into fragile, sequential fetch logic.
As applications grow beyond simple CRUD screens, server data starts to form chains of dependency. A page may need the current user before it can fetch an organization. It may need an organization before it can load permissions, billing details, or feature flags. None of these requests is optional, but none of them can start at the same time either.
In many React codebases, this reality leads to imperative orchestration inside components. One useEffect fetches user data and stores an ID in the state. Another effect watches that ID and triggers the next request. Loading flags multiply. Components re-render not because the UI changed, but because data-fetching state advanced one step further down the chain. The UI becomes tightly coupled to the process of fetching, rather than the truth of server state.
This approach creates predictable problems. Fetches accidentally serialize into waterfalls even when data could be reused from cache. Navigating away and back restarts chains unnecessarily. Small timing changes cause visible flicker as intermediate “empty” states appear. Most importantly, the logic that determines when data is allowed to exist lives inside component render cycles, where it is hardest to reason about and easiest to break.
React Query addresses this problem by moving dependency management out of component logic and into the data layer. Instead of manually sequencing fetches, we describe when a piece of server state is meaningful, and let the cache decide when to activate it. This reframes dependent data from an imperative workflow into a declarative relationship between queries.
The above diagram compares two flows. On the left, a component triggers fetch A, waits in local state, then triggers fetch B inside an effect, causing multiple re-renders and visible loading transitions. On the right, two queries are registered with the cache. Query A is active immediately. Query B is registered but disabled until Query A provides an ID. Once available, the cache activates Query B, fetches data, and updates all subscribers in one coordinated step.
Rendering snapshots with dependent queries
A dependent query is not a query that waits for another query to finish. It is a query whose activation depends on the server truth produced elsewhere. The first query resolves something fundamental: an identifier, a scope, a capability. The second query represents a distinct piece of server state that only makes sense once that prerequisite exists.
React Query models this by allowing queries to be conditionally enabled. The dependent query is registered with the cache immediately, but remains inactive until its enabling condition becomes true. Crucially, this does not tie the dependent query to a specific render or effect. Its lifecycle belongs to the cache, not to the component.
This ...