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
+16Lines changed: 16 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -187,6 +187,14 @@ Infinite query hooks return [the same result object as normal query hooks](./que
187
187
188
188
In most cases, you will probably read `data` and either `isLoading` or `isFetching` in order to render your UI. You will also want to use the `fetchNext/PreviousPage` methods to trigger fetching additional pages.
189
189
190
+
### Displaying Infinite Query Data
191
+
192
+
For infinite query hooks, the `data` field returned by the hook will be the `{pages, pageParams}` structure containing all fetched pages, instead of just a single response value.
193
+
194
+
This gives you control over how the data is used for display. You can flatten all the page contents into a single array for infinite scrolling, use the individual page results for pagination, sort or reverse the entries, or any other logic you need for rendering the UI with this data.
195
+
196
+
As with any other Redux data, you should avoid mutating these arrays (including calling `array.sort/reverse()` directly on the existing references).
197
+
190
198
### Infinite Query Hook Usage Example
191
199
192
200
Here is an example of a typical infinite query endpoint definition, and hook usage in a component:
@@ -248,6 +256,12 @@ Similarly, this example relies on manual user clicks on a "Fetch More" button to
248
256
249
257
The endpoint itself only defines `getNextPageParam`, so this example doesn't support fetching backwards, but that can be provided in cases where backwards fetching makes sense. The page param here is a simple incremented number, but the page param
250
258
259
+
## Refetching
260
+
261
+
When an infinite query endpoint is refetched (due to tag invalidation, polling, arg change configuration, or manual refetching), RTK Query will try to sequentially refetch all pages currently in the cache. This ensures that the client is always working with the latest data, and avoids stale cursors or duplicate records.
262
+
263
+
If the cache entry is ever removed and then re-added, it will start with only fetching the initial page.
264
+
251
265
## Limiting Cache Entry Size
252
266
253
267
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.
@@ -260,6 +274,8 @@ The `getNext/PreviousPageParam` callbacks offer flexibility in how you interact
260
274
261
275
Here are some examples of common infinite query patterns to show how you might approach different use cases.
262
276
277
+
For additional examples, and to see some of these patterns in action, see [the RTK Query "infinite queries" example app in the repo](https://github.com/reduxjs/redux-toolkit/tree/master/examples/query/react/infinite-queries).
278
+
263
279
### Basic Pagination
264
280
265
281
For a simple API that just needs page numbers, you can calculate the previous and next page numbers based on the existing page params:
Uses [Vite](https://vitejs.dev/), [Vitest](https://vitest.dev/), and [React Testing Library](https://github.com/testing-library/react-testing-library) to create a modern [React](https://react.dev/) app compatible with [Create React App](https://create-react-app.dev/)
3
+
This example shows a variety of usage patterns for RTK Query's infinite query endpoint support, including:
0 commit comments