Pagination

Use a ready RPC or HTTP utility tree. In these examples, users.page accepts numeric cursor and pageSize fields and returns { users, nextCursor }, with null marking the last page.

Build page options

Map each page parameter to RPC payload constructor input:

const rpcPages = rpc.users.page.infiniteOptions({
  initialPageParam: 0,
  input: (cursor) => ({ cursor, pageSize: 20 }),
  getNextPageParam: (page) => page.nextCursor ?? undefined,
})
const pages = await queryClient.infiniteQuery(rpcPages)

For HTTP, return every declared request container from the mapper:

const httpPages = http.users.page.infiniteOptions({
  initialPageParam: 0,
  input: (cursor) => ({ query: { cursor, pageSize: 20 } }),
  getNextPageParam: (page) => page.nextCursor ?? undefined,
})

Pass these options to the native infinite-query hook to load further pages with fetchNextPage. Inputless operations omit input. Input-bearing operations can pause with input: skipToken. See Conditional Queries.

Keep page identity stable

The mapped initial request determines cache identity. Include filters in that request and every page. When filters change, rebuild the options. The mapper runs during key construction and page execution, so keep it deterministic.

TanStack stores pages and pageParams. A native select can flatten returned data. Cache reads retain the original pages and inferred page-parameter type:

const cachedPages = queryClient.getQueryData(httpPages.queryKey)

Infinite views have separate keys from ordinary queries. Every page uses the query runner and abort signal. See RPC Builders and HTTP Builders for exact option contracts.