Apollo Client
React
GraphQL
conditional queries
JavaScript

How to fetch multiple conditional queries in Apollo Client React?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

In Apollo Client React, multiple conditional queries usually mean one of two things: some queries should only run when required variables exist, or one query depends on the result of another. The cleanest pattern is to keep each query separate and conditionally start it with skipToken or useLazyQuery.

Start a Query Only When Its Inputs Exist

Apollo’s skipToken API is a good fit when a query should not run until required input is available:

tsx
1import { skipToken, useQuery } from "@apollo/client/react";
2
3const userResult = useQuery(
4  GET_USER,
5  userId ? { variables: { userId } } : skipToken
6);
7
8const ordersResult = useQuery(
9  GET_ORDERS,
10  userId ? { variables: { userId } } : skipToken
11);

Each query lives in the component, but it does not execute until its condition is satisfied.

Chain a Query from Earlier Query Data

If the second query depends on the first query’s result, derive the second query’s variables from that data and skip until they exist:

tsx
1const userResult = useQuery(GET_USER, {
2  variables: { email },
3});
4
5const accountId = userResult.data?.user.accountId;
6
7const accountResult = useQuery(
8  GET_ACCOUNT,
9  accountId ? { variables: { accountId } } : skipToken
10);

This is usually clearer than manually coordinating network calls with useEffect.

Use useLazyQuery for Event-Driven Fetching

If a query should run only after a user action, useLazyQuery is often a better fit:

tsx
1import { useLazyQuery } from "@apollo/client/react";
2
3const [loadReports, reportsResult] = useLazyQuery(GET_REPORTS);
4
5function handleClick() {
6  loadReports({ variables: { teamId } });
7}

This works well for buttons, expandable sections, on-demand dialogs, and search screens where automatic querying would be wasteful.

Keep Separate Conditions Separate

Developers sometimes try to force several unrelated conditional data fetches into one oversized GraphQL operation. That can make the query document harder to read and can fetch fields you do not actually need.

If the conditions are different, separate hooks are often the better design. Apollo’s cache can still help those hooks share data efficiently.

Combine Loading and Error States Intentionally

With multiple conditional queries, the UI needs to decide how loading and error states compose:

tsx
1const loading = userResult.loading || accountResult.loading;
2const error = userResult.error ?? accountResult.error;
3
4if (loading) return <Spinner />;
5if (error) return <ErrorPanel message={error.message} />;

This keeps rendering logic predictable instead of scattering status checks throughout the component body.

It also makes it easier to refactor later if one query moves into a child component or a route-level boundary.

That small discipline pays off quickly in larger React trees.

Common Pitfalls

The biggest mistake is firing queries with incomplete variables and then trying to recover from errors or empty states. Skip them until the inputs are truly ready.

Another common issue is reaching for useEffect immediately when a declarative useQuery(..., condition ? options : skipToken) pattern would be simpler.

People also forget that one conditional query can depend on another query’s data. In that case, derive the second query’s variables from the first result rather than duplicating state.

Finally, not every query should run on render. For user-triggered fetches, useLazyQuery is often the clearest answer.

Summary

  • Use skipToken when a query should not run until required variables exist.
  • Chain dependent queries by deriving later variables from earlier query results.
  • Use useLazyQuery for event-driven or user-triggered fetching.
  • Keep unrelated conditional queries separate instead of forcing one oversized GraphQL operation.
  • Prefer declarative query conditions over manual orchestration when possible.

Course illustration
Course illustration

All Rights Reserved.