You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/rtk-query/usage/infinite-queries.mdx
+258-2Lines changed: 258 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ With standard query endpoints:
31
31
Infinite queries work similarly, but have a couple additional layers:
32
32
33
33
- You still specify a "query arg", which is still used to generate the unique cache key for this specific cache entry
34
-
- However, there is a separation between the "query arg" used for the cache key, and the "page param" used to fetch a specific page. Since both are useful for determining what to fetch, your `query` and `queryFn` methods will receive a combined object with `{queryArg, pageParam}` as the first argument, instead of just the `queryArg` by itself.
34
+
- However, there is a separation between the "query arg" used for the cache key, and the "page param" used to fetch a specific page. Since both are useful for determining what to fetch, **your `query` and `queryFn` methods will receive a combined object with `{queryArg, pageParam}` as the first argument, instead of just the `queryArg` by itself**.
35
35
- The `data` field in the cache entry stores a `{pages: DataType[], pageParams: PageParam[]}` structure that contains _all_ of the fetched page results and their corresponding page params used to fetch them.
36
36
37
37
For example, a Pokemon API endpoint might have a string query arg like `"fire"`, but use a page number as the param to determine which page to fetch out of the results. For a query like `useGetPokemonInfiniteQuery('fire')`, the resulting cache data might look like this:
@@ -75,7 +75,7 @@ The `infiniteQueryOptions` field includes:
75
75
-`getPreviousPageParam`: an optional callback that will be used to calculate the previous page param, if you try to fetch backwards.
76
76
77
77
Both `initialPageParam` and `getNextPageParam` are required, to
78
-
ensure the infinite query can properly fetch the next page of data.Also, `initialPageParam` may be specified when using the endpoint, to override the default value for a first fetch. `maxPages` and `getPreviousPageParam` are both optional.
78
+
ensure the infinite query can properly fetch the next page of data.Also, `initialPageParam` may be specified when using the endpoint, to override the default value for a first fetch. `maxPages` and `getPreviousPageParam` are both optional.
// Optionally provide a `getPreviousPageParam` function
121
125
getPreviousPageParam: (
122
126
firstPage,
123
127
allPages,
@@ -249,3 +253,255 @@ The endpoint itself only defines `getNextPageParam`, so this example doesn't sup
249
253
All fetched pages for a given query arg are stored in the `pages` array in that cache entry. By default, there is no limit to the number of stored pages - if you call `fetchNextPage()` 1000 times, `data.pages` will have 1000 pages stored.
250
254
251
255
If you need to limit the number of stored pages (for reasons like memory usage), you can supply a `maxPages` option as part of the endpoint. If provided, fetching a page when already at the max will automatically drop the last page in the opposite direction. For example, with `maxPages: 3` and a cached page params of `[1, 2, 3]`, calling `fetchNextPage()` would result in page `1` being dropped and the new cached pages being `[2, 3, 4]`. From there, calling `fetchNextPage()` would result in `[3, 4, 5]`, or calling `fetchPreviousPage()` would go back to `[1, 2, 3]`.
256
+
257
+
## Common Infinite Query Patterns
258
+
259
+
The `getNext/PreviousPageParam` callbacks offer flexibility in how you interact with the backend API.
260
+
261
+
Here are some examples of common infinite query patterns to show how you might approach different use cases.
262
+
263
+
### Basic Pagination
264
+
265
+
For a simple API that just needs page numbers, you can calculate the previous and next page numbers based on the existing page params:
For an API that accepts values like page number and page size and includes total pages in the response, you can calculate whether there are more pages remaining:
0 commit comments