使用 ApolloClient 分页 API 导致请求，即使所有页面内容都已在缓存中

Question

I am using the ApolloClient core pagination API approach to accumulate paginated requests in a merge function and the repaginate them with a read function: https://www.apollographql.com/docs/react/pagination/core-api

This all works, but now there is a request for each page, even the ones that are already in the cache.

Which defeats the whole purpose when I'm repaginating!

I'm using the default fetchStrategy , cache-first .

If all requested data is present in the cache, that data is returned. Otherwise, Apollo Client executes the query against your GraphQL server and returns that data after caching it.

I wonder how ApolloClient checks that all requested data is in the cache with the pagination implementation.

Because right now (and the docs seems to rely on this) it always does the request, even when the keyArgs match and the data is in the cache.

Does someone know what causes this and how I can customize this cache-first strategy to check if all the items of the requested page are already in the cache?

Here is my code, in case that helps for context or if I'm just doing something wrong:

        typePolicies: {
          Query: {
            fields: {
              paginatedProductTracking: {
                // Include everything except 'skip' and 'take' to be able to use `fetchMore`
                //  and repaginate when reading cache
                //  (essential for switching between desktop pagination and mobile lazy loading
                //   without having to refetch)
                keyArgs: (args) => JSON.stringify(omit(args, ['query.skip', 'query.take'])),
                merge: (existing, incoming, { args }) => {
                  if (!existing) {
                    return incoming;
                  }
                  if (!incoming) {
                    return existing;
                  }
                  const data = existing.paginatedData;
                  const newData = incoming.paginatedData;
                  return {
                    ...existing,
                    // conservative merge that is robust against pages being requested out of order
                    paginatedData: [
                      ...data.slice(0, args?.query.skip || 0),
                      ...newData,
                      ...data.slice((args?.query.skip || 0) + newData.length),
                    ],
                  };
                },
              },
            },
          },
        },

  const [pageSize, setPageSize] = useState(100);
  const [page, setPage] = useState(0);
  const skip = page * pageSize;

  const query = {
    filter,
    aggregationInterval,
    order,
    skip,
    take: pageSize,
    search: search ? values : null,
    locations: currentLocations.length > 0 ? currentLocations.map((location) => location.id) : undefined,
  };

  const { data, loading, fetchMore } = useProductTrackingAggregatedDataQuery({
    variables: {
      query,
    },
  });

      onPageChange={async (newPage) => {
        await fetchMore({
          variables: {
            query: {
              ...query,
              skip: newPage * pageSize,
            },
          },
        });
        setPage(newPage);
      }}

Answer 1

I was recently faced with the exact same issue and had everything implemented in the way the official documentation illustrates until I stumbled upon this issue which is still open so I'm guessing this is still how the fetchMore function actually behaves to date. So @benjamn says that:

The fetchMore method sends a separate request that always has a fetch policy of no-cache, which is why it doesn't try to read from the cache first.

This being the case, fetchMore is only useful if you are implementing an endless scroll sort of pagination where you know beforehand that the new data is not in the cache.

In the pagination documentation it also states that:

If you are not using React and useQuery, the ObservableQuery object returned by client.watchQuery has a method called setVariables that you can call to update the original variables.

If you change the variables to your query it will trigger your read function implementation. And if the read function finds the data within existing it can return them or return undefined which will in turn trigger a.network request to your graphql server to fetch the missing data, which will trigger your merge function to merge the data in the desired way, which will again trigger the read function which will now be able to slice the data you requested according to your { args } out of your existing and return them, which will finally trigger your watched ObservableQuery to fire and your UI to be updated.

Now, this approach is counter intuitive and goes against the "recommended" way of implementing pagination, but contrary to the recommended way this approach actually works.

I was unable to find anything that would prove my conclusions about fetchMore to be wrong, so if any Apollo client guru happens to stumble upon this please do shed some light into this. Until then the only solution I can offer is working with setVariables instead of fetchMore.

Keep in mind that you will need to implement a read function along with your merge. It will be responsible for slicing your cached data and triggering a.network request by returning undefined if it was unable to find a full slice.