Expose the full response from queryFn on utils.queryData #809
+394
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Comprehensive investigation of Discord user's feature request to support returning extra pagination info (like total_count) from queryFn in queryCollectionOptions. Key findings: - The full query response IS cached in TanStack Query already - The select function extracts just the array portion - But metadata is not accessible through collection.utils API - Current workaround requires direct queryClient.getQueryData() access Recommended solution: Add queryData property to QueryCollectionUtils to expose the full query response in a reactive, type-safe way. This would enable clean TanStack Table integration with pagination metadata without hacky workarounds like duplicating total_count into every item.
…y response
Implements support for accessing pagination metadata and other API response
info from queryCollectionOptions. Resolves Discord feature request from
Amir Hoseinian about returning extra pagination info.
Changes:
- Add queryData property to QueryCollectionUtils interface
- Store full query response in internal state when query succeeds
- Expose queryData via utils getter for reactive access
- Add comprehensive test coverage (4 new tests)
- Add detailed documentation with examples
The queryData property provides access to the full queryFn response,
including metadata that was previously inaccessible after using select()
to extract the array portion. This enables clean TanStack Table integration
with pagination info and other API metadata.
Example usage:
```typescript
const collection = createCollection(
queryCollectionOptions({
queryFn: async () => ({
data: await api.getContacts(),
total: pagination.total_count
}),
select: (response) => response.data,
// ...
})
)
const totalCount = collection.utils.queryData?.total
```
Benefits:
- Type-safe metadata access
- Reactive updates on refetch
- No need to duplicate metadata into items
- Cleaner API than accessing queryClient directly
- Perfect for server-side pagination with TanStack Table
Tests: All 145 tests passing
Coverage: 86.5% statements, 84.52% branches
🦋 Changeset detectedLatest commit: fb31e81 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
More templates
@tanstack/angular-db
@tanstack/db
@tanstack/db-ivm
@tanstack/electric-db-collection
@tanstack/offline-transactions
@tanstack/powersync-db-collection
@tanstack/query-db-collection
@tanstack/react-db
@tanstack/rxdb-db-collection
@tanstack/solid-db
@tanstack/svelte-db
@tanstack/trailbase-db-collection
@tanstack/vue-db
commit: |
Contributor
|
Size Change: 0 B Total Size: 86 kB ℹ️ View Unchanged
|
Contributor
|
Size Change: 0 B Total Size: 3.34 kB ℹ️ View Unchanged
|
kevin-dp
approved these changes
Nov 17, 2025
| TKey extends string | number = string | number, | ||
| TInsertInput extends object = TItem, | ||
| TError = unknown, | ||
| TQueryData = any, |
Contributor
There was a problem hiding this comment.
Should this be unknown rather than any?
| lastError: any | ||
| errorCount: number | ||
| lastErrorUpdatedAt: number | ||
| queryData: any |
Contributor
There was a problem hiding this comment.
Shouldn't this be TQueryData instead of any?
| lastError: undefined as any, | ||
| errorCount: 0, | ||
| lastErrorUpdatedAt: 0, | ||
| queryData: undefined as any, |
Contributor
There was a problem hiding this comment.
Do we really need to type it as any?
samwillis
reviewed
Nov 17, 2025
Collaborator
samwillis
left a comment
samwillis
left a comment
There was a problem hiding this comment.
@KyleAMathews note that this exposes the data from the last query function. So when used in on-demand it will be the last response for the most recent loadSubset call. I think we need to consider if this is the right API with the 1:n query:collection design.
Comment on lines
+321
to
+325
| - `isFetching`: Whether the query is currently fetching | ||
| - `isRefetching`: Whether the query is refetching in the background | ||
| - `isLoading`: Whether the query is loading for the first time | ||
| - `dataUpdatedAt`: Timestamp of the last successful data update | ||
| - `fetchStatus`: Current fetch status (`'fetching'`, `'paused'`, or `'idle'`) |
Collaborator
There was a problem hiding this comment.
With us having 1:n collection to query the isXX return true when any of the queries are in that state, dataUpdatedAt is the most recent query update time, and fetchStatus is an array of statuses.
Collaborator
Author
Hmm yeah you're right. We need to all download all these ideas about query collection & step back and have a rethink. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.