`fetchMore` causes redundant request with fetchPolicy `network-only` and `cache-and-network`

Intended outcome: Calling fetchMore causes single network request when query fetchPolicy is network-only or cache-and-network.

Actual outcome: fetchMore causes two requests: one for fetching requested page and second is always refetching first page.

How to reproduce the issue:

1. open repro https://codesandbox.io/s/nostalgic-sammet-wlhrq?file=/src/Todos.tsx
2. open network inspector
3. click “Load more”
4. inspect requests inside wlhrq.csb.app frame, you will see two requests for every next page load

Versions

System:
  OS: macOS 11.1
Binaries:
  Node: 14.15.4 - /usr/local/bin/node
  Yarn: 1.12.3 - /usr/local/bin/yarn
  npm: 6.14.10 - /usr/local/bin/npm
Browsers:
  Chrome: 88.0.4324.150
  Safari: 14.0.2

[picosam]

@gbiryukov The client is doing exactly what you’ve asked it to do here!

Since fetchMore works by updating the cache, if you want to render those updates without making an additional network request, you need a fetchPolicy that’s allowed to read from the cache, rather than (just) network-only. If you stick with fetchPolicy: "network-only" after the first request, the client’s only option for responding to cache updates from fetchMore is to perform an additional network request. The cache-and-network policy allows reading from the cache, which is a step in the right direction, but it also makes an unconditional network request, so that’s not exactly what you want. Here’s a summary of the history of these behaviors, in case you’re curious: #6760 (comment)

Based on your description of the problem, I would guess you want the first query to be network-only, but you want to switch back to cache-first for subsequent queries. Thanks to #6712, we now have an easy way to achieve that (namely, the nextFetchPolicy option):

const { data, fetchMore, networkStatus } = useQuery<Todos>(TODOS_QUERY, {
  fetchPolicy: "network-only",
  nextFetchPolicy: "cache-first", // this line
  notifyOnNetworkStatusChange: true,
  variables: {
    options: {
      paginate: {
        page: 0,
        limit: 5
      }
    }
  }
});

Please use nextFetchPolicy instead of monkey-patching fetchMore.

Thank you. I tried this resolution but, try as I may, each fetchMore always hits the network and never hits the cache. Even though I simulated calling it with the same limit and offset variables, and I tried putting them in keyArgs and removing them from there. Nothing works. My use case is a table that fetches more data on scrolling, but that should get the data from the cache when scrolling back upwards.

[benjamn]

@gbiryukov The client is doing exactly what you’ve asked it to do here!

Since fetchMore works by updating the cache, if you want to render those updates without making an additional network request, you need a fetchPolicy that’s allowed to read from the cache, rather than (just) network-only. If you stick with fetchPolicy: "network-only" after the first request, the client’s only option for responding to cache updates from fetchMore is to perform an additional network request. The cache-and-network policy allows reading from the cache, which is a step in the right direction, but it also makes an unconditional network request, so that’s not exactly what you want. Here’s a summary of the history of these behaviors, in case you’re curious: https://github.com/apollographql/apollo-client/issues/6760#issuecomment-668188727

Based on your description of the problem, I would guess you want the first query to be network-only, but you want to switch back to cache-first for subsequent queries. Thanks to #6712, we now have an easy way to achieve that (namely, the nextFetchPolicy option):

const { data, fetchMore, networkStatus } = useQuery<Todos>(TODOS_QUERY, {
  fetchPolicy: "network-only",
  nextFetchPolicy: "cache-first", // this line
  notifyOnNetworkStatusChange: true,
  variables: {
    options: {
      paginate: {
        page: 0,
        limit: 5
      }
    }
  }
});

Please use nextFetchPolicy instead of monkey-patching fetchMore.