Work aroundrefetchPage removal in v5

[xobotyi]

As for v5 there is no more way to refetch last page of infinite query.

Option we've been given instead does the other thing than giving the ability to refetch last page of query - i dont want to limit amount of pages.

Our logic implies that entities in the feed can be changed, but only for the case when it is the last entiry. Given functionality is not achievable with new version, or i've missed something?

[PedroJBrito]

We're facing a similar problem. We have a list that uses useInfiniteQuery and we have some use cases where we need to invalidate only one of the pages. In v4, we used invalidateQueries and, with refetchPage, we compared the index of the page returned with the index of the page we wanted to fetch and only returned true if it matched.

Something like:

queryClient.invalidateQueries(queryKey, {
  exact: true,
  refetchPage: (_, index) => index === targetPage,
});

Since this option has been removed in v5, how am I supposed to get the same behavior?

[xobotyi]

As for me - old-to-new timeline.
Actually it can be any feed with stable pages. In case new elements are added to the end of list - it does not cause shift in pages content therefore refetch of any page is safe.

[PedroJBrito]

We have an infinite list of items, where each row shows various data relating to those items (date, status, ...), and we can click on those items to open a detail modal. In this modal, we can edit the item and, once saved, the modal is closed, but we need to update the list, as the status may have been updated, for example. As we know which page the updated item belongs to, in v4 we were only updating the necessary page, but we don't know how to achieve the same behavior in v5.

[TkDodo]

For both these cases I would say that you can:

• either don't invalidate after the mutation, but update the one item from the mutation response.
• use the pattern I've shown below to only refetch a single page. It makes the queryFn run for all items, but doesn't call fetch unless you deem it necessary.

[PedroJBrito]

Thanks @TkDodo. Regarding the second approach, I'm not sure I understand your point. Where would you put this queryFn? In the useInfiniteQuery? If I want to update a specific page after a mutation, how do I do that with this approach?

[TkDodo]

yes, it's the queryFn for useInfiniteQuery. The idea is to "detect" a refetch by looking up if we already have data for the passed pageParam in the cache and then potentially just return this if we don't want to refetch it.

If I want to update a specific page after a mutation, how do I do that with this approach?

The example was for "I only want to refetch the last page", because that was the original question. It gets more complicated if you want to refetch page X because you'd need to provide an index to the queryFn, likely via meta and a ref. Tbh, I would just stop here and tell you it's not possible, sorry, because its too much hassle.

Infinite Queries aren't designed to view a single page in isolation. It's one cache entry that is chunked up into multiple fetches. That's why the refetchPage api was a mistake. Sorry if you've been using it and can't use it anymore now. You can always just fire a single fetch(...) without RQ and then update the cache with setQueryData with what you get back. But out of the box, it's not something I'd want to support.

[TkDodo]

Our logic implies that entities in the feed can be changed, but only for the case when it is the last entry. Given functionality is not achievable with new version, or i've missed something?

I'd still refetch everything but let the queryFn "bail out" if it's not the last entry. something like:

queryFn: ({ pageParam, queryKey }) => {
  const cachedData = queryClient.getQueryData(queryKey)
  if (cachedData) {
    const index = cachedData.pageParams.findIndex((p) => p === pageParam)
    const data = cachedData.pages[index]
    const shouldFetch = index === cachedData.pages.length - 1
    return shouldFetch ? fetch(...) : data
  }
  return fetch(...)
},

I think we could make this a bit easier on our end by passing more information into the queryFn so you don't have to retrieve it manually, but it should be possible like shown before. It basically means that in the queryFn, you look up if you should fetch the next page or not, and if not, you just return the data that is currently in the cache instead of actually fetching.