Infinite queries and refetching pages

[markerikson]

( Pasted from #4738 (comment) by @Abdullah-Nazardeen):

Hi, RTK Query Team!

I’m currently implementing infinite scroll in my application using RTK Query, and I’ve encountered a challenge related to editing rows and refetching specific data batches.

Here’s the scenario:

Infinite Scroll Setup:

Data is fetched in batches of 100 rows (e.g., rows 0–99, 100–199, etc.).
New data is loaded as the user scrolls down the table.
Editing Rows:

Users can edit individual rows in the table.
For example, if the user edits the 260th row, I want to invalidate and refetch only the batch containing that row (i.e., rows 200–299).
The Challenge:
How can I structure my RTK Query setup to allow invalidating and refetching a specific batch (based on the row index) without refetching all the other batches?

I’ve considered using:

Tags: Associating tags with specific batches (e.g., batch 200–299).
Custom Query Keys: Dynamically generating query keys based on pagination parameters.
However, I’m unsure about the best way to achieve this efficiently while maintaining compatibility with infinite scrolling and avoiding unnecessary refetches.

Additional Context:

I’m using RTK Query’s useQuery for fetching data and invalidateTags for cache management.
My current setup works well for infinite scroll but lacks fine-grained invalidation for specific batches.
Could you provide guidance or suggest best practices for implementing this use case using the new infinite query? Any help would be greatly appreciated!

[markerikson]

@Abdullah-Nazardeen : what does your current API definition setup look like?

The new infinite query API is not designed for invalidating specific pages, only the entire cache entry with all the pages.

[BenQoder]

Or we can just avoid invalidating specific pages for infinite scrolling altogether. Because in most cases, all new list items are just appended at the end of the list old list, and if a page refresh or pull-to-refresh is done, the page starts from Page 1 again, or if its a cursor pagination, the cursor becomes undefined again.

What I think is more important, is ability to modify specific item in the list something like what we already have using Optimistic updates