How to prevent scroll jumping when invalidating InfiniteQuery that has fetched multiple pages

[bywo]

I've run into an issue where I have an infinite scroll list backed by a useInfiniteQuery. After scrolling far enough to trigger fetching of multiple pages, I invalidate the query. As documented, the InfiniteQuery then refetches the pages sequentially. Unfortunately, this means that the hook triggers a rerender with 1 page of data, and then 2 pages of data. This subsequently causes my content height to shrink, and then grow again, causing the scroll to jump.

Is there way around this? One solution I'm imagining is a flag that tells InfiniteQuery to not trigger rerender until all pages have been refetched.

[TkDodo]

Unfortunately, this means that the hook triggers a rerender with 1 page of data, and then 2 pages of data.

I am not positive that this is what is happening / should be happening. When you have two pages in the cache, and you invalidate, what you should be seeing on screen is:

- old page 1 / old page 2
- invalidate
- new page 1 / old page 2
- new page 1 / new page 2

because react query doesn't remove any data from the cache, it just replaces the stale data with new data. So I'm not sure how content height would be affected by the refetches - unless of course different items are fetched that render differently.

Can you provide a codesandbox reproduction?

[bywo]

Thanks for the quick reply @TkDodo! You're right, the refetched pages come in one-by-one without deleting other pages. I had written some extra code to combine all pages into one page and replacing the value in the cache, which caused the issue I was seeing. The built-in behavior of react-query works as expected, so I don't think there are any changes to be made.

[bywo]

Follow up question: Say we have an infinite list of FeedItems (imagine Instagram), how would you model optimistically creating a new FeedItem at the top of the feed? In this example, the backend serves 5 items per page.

Option A: prepend the new item to the first page via queryClient.setQueryData()

Before:
    page 1 [A, B, C, D, E], page 2 [F, G, H, I, J]
After optimistic update:
    page 1 [AA, A, B, C, D, E], page 2 [F, G, H, I, J]
After invalidate and first fetch:
    page 1 [AA, A, B, C, D], page 2 [F, G, H, I, J]
After invalidate and second fetch:
    page 1 [AA, A, B, C, D], page 2 [E, F, G, H, I]

Note that while the pages are being refetched, Item E disappears for a moment.

Option B: prepend the new item, and re-slice the pages to the correct pageSize via queryClient.setQueryData()

Before:
    page 1 [A, B, C, D, E], page 2 [F, G, H, I, J]
After optimistic update:
    page 1 [AA, A, B, C, D], page 2 [E, F, G, H, I], page 3 [J]
After invalidate and first fetch:
    page 1 [AA, A, B, C, D], page 2 [E, F, G, H, I], page 3 [J]
After invalidate and second fetch:
    page 1 [AA, A, B, C, D], page 2 [E, F, G, H, I], page 3 [J]
I haven't tested whether page 3 would get refetched or not.

With this option, we don't have the "disappearing item" problem. However, the problem with this is that data.pageParams will probably be incorrect after the modification, and I'm not able to generate correct pageParams on the client.

What do you think?

[TkDodo]

option C: don't do optimistic updates in that case ;)

if you do B, just make sure that you also slice pageParams correctly and then it should work. But every time you have to create lots of logic on the frontend to mirror what the backend is doing, optimistic updates become less impressive.

For example, we have a list of items that the user can sort (by various fields). We allow a mutation that changes the name of an item displayed in the list. optimistic updates sound straight forward - up to the point where the user has sorted the list by the name and the update would actually move the item to a different position.

Now we could re-sort optimistically, duplicating the logic the sorting logic that the backend does on the frontend, or we could just not do an optimistic update. we opted for the second solution: less code, always correct, slightly different (worse?) ux.