Implementing Offset‑Based Pagination in Apollo Client with InMemoryCache

Useful answer

Apollo Client’s InMemoryCache can keep each page of an offset‑based list under a distinct cache key. When you call fetchMore with updated offset and limit variables, Apollo merges the newly returned items into the existing list, so the UI shows a growing collection without a full reload.

Mechanism – worked example

Below is a minimal React component that demonstrates the pattern. It assumes you have already installed @apollo/client and graphql packages.

import { gql, useQuery } from '@apollo/client';

const FEED_QUERY = gql`
  query Feed($offset: Int!, $limit: Int!) {
    feed(offset: $offset, limit: $limit) {
      id
      text
    }
  }
  @connection(key: "feed", filter: ["offset", "limit"])
`;

function Feed() {
  const { data, loading, error, fetchMore, refetch } = useQuery(FEED_QUERY, {
    variables: { offset: 0, limit: 10 },
    fetchPolicy: 'cache-and-network',
  });

  const loadMore = () => {
    if (!data) return;
    fetchMore({
      variables: {
        offset: data.feed.length, // next page starts after current items
        limit: 10
      },
      updateQuery: (prev, { fetchMoreResult }) => {
        if (!fetchMoreResult) return prev;
        return {
          feed: [...prev.feed, ...fetchMoreResult.feed]
        };
      }
    });
  };

  if (loading) return 
Loading…
;
  if (error) return 
Error: {error.message}
;

  return (
    
      

        {data.feed.map(item => (
          
{item.text}
        ))}
      
      
        Load more
      
    
  );
}

export default Feed;

Where to run:

• Save the component in your React source tree (e.g., src/components/Feed.jsx).
• Ensure an ApolloClient instance is wrapped around your app with an InMemoryCache (default setup).
• Run the app with npm start or your usual dev server.

Required permissions: none beyond normal frontend execution; the component only reads from the GraphQL endpoint you configured in ApolloClient.

Placeholders:

• FEED_QUERY – replace feed with your actual connection field.
• offset and limit – adjust to match your backend’s pagination arguments.
• The @connection directive’s key must be unique across queries; here we use "feed".

Expected checks:

• Open Apollo Client DevTools → Cache → ROOT_QUERY. You should see separate entries like feed({"offset":0,"limit":10}) and feed({"offset":10,"limit":10}).
• In the Network tab, each click of “Load more” triggers a single GraphQL request with the updated offset variable; no full refetch occurs.
• The rendered list grows by exactly the number of items returned per page, with no duplicates.

Risks:

• If the underlying data changes between requests (items inserted or deleted), offset‑based pagination can show duplicates or skip items.
• Using a non‑unique @connection key causes different pages to share the same cache entry, leading to overwritten data.
• Mutating the array returned by fetchMore (e.g., data.feed.push(...)) breaks Apollo’s immutable merge expectations and can corrupt the cache.

Limits

Offset‑based pagination works best when:

• The dataset is relatively small or changes infrequently.
• You can tolerate occasional duplicates or missed items in exchange for simpler implementation.

For highly dynamic data, consider keyset (cursor‑based) pagination or refetching the whole list after a mutation.

Common mistakes and how to avoid them

1. Missing or incorrect @connection directive. Without it, fetchMore treats the new result as a full replacement, so the list resets to the latest page. Fix: Always include @connection(key: "uniqueKey", filter: ["offset", "limit"]) and ensure the filter arrays contain every variable that affects the query result.
2. Updating the offset variable incorrectly. Using a static offset (e.g., always 0) causes the same page to be refetched repeatedly, leading to an infinite loop or stale UI. Fix: Set the new offset to previousResult.length (or the total count you already have).
3. Mutating the fetched data. Some developers push new items directly into the array returned by fetchMore. This interferes with Apollo’s internal merge and can cause cache inconsistencies. Fix: Let Apollo handle the merge via the updateQuery function (as shown) or rely on the default concatenation behavior when you return Object.assign({}, prev, { feed: [...prev.feed, ...fetchMoreResult.feed] }).

Practical way to verify the result

1. Run the component in a development environment.
2. Open Apollo Client DevTools (install the browser extension if needed).
3. Select the Cache tab, expand ROOT_QUERY, and verify that each page offset creates a distinct cache entry.
4. Click “Load more” several times and confirm that the Network tab shows only one incremental request per click, with the correct offset value.
5. Check the rendered list: it should contain the concatenation of all fetched pages without repeated items.