Solutions for overfetching in useInfiniteQuery invalidations

[williamlmao]

Background
I have a chat app that uses useInfiniteQuery to load the messages. When a new message comes in, I get a realtime event, which triggers an invalidateQueries. I cannot simply update the query cache with the realtime event because the data I get from the realtime event is incomplete.

The Problem
If a user scrolls up to load more messages, or has been on the window for long enough, they will have many pages loaded in the query cache. Each time an event comes in, every single page gets refetched sequentially by invalidateQueries. This can mean that the endpoint gets hit 20-30 times anytime a new message comes in, and continues to grow the longer a user is on the app.

At first, I thought I could use some configuration to say only refetch the most recent page. I found refetchPages, but that was deprecated in favor of maxPages. However, I can't use that because this would prevent someone from scrolling all the way up in their chat history.

A Side Quest
As a quick side quest, another issue I have is that I invalidate this query from multiple parts of my app, and now I'm finding that I end up refetching this data way too often in combination with the problem I talked about above. This is obviously a problem I could solve with better code, but just throwing in a quick pitch for a configuration option refetchCooldown.

The way I would hope this would work is when I pass in refetchCooldown: 1000, it means that once an invalidation is triggered and the query begins to refetch, any other invalidations within that time frame would not trigger additional refetching.

tl;dr
I can see that I am sending waaaaay too many requests to fetch messages, and I'm not sure what the right solution is here. Does anyone have any ideas? Thanks!

[TkDodo]

However, I can't use that because this would prevent someone from scrolling all the way up in their chat history.

yeah you would have to implement bidirectional infinite queries.

This can mean that the endpoint gets hit 20-30 times anytime a new message comes in, and continues to grow the longer a user is on the app.

an alternative to invalidation is to just fire a manual fetch call for the specific message when the event comes in and then put the result into the correct position at the cache with queryClient.setQueryData