Can no longer remove active queries by setting there nextFetchPolicy to standby

[jrans]

Issue Description

On updating @apollo/client from v3.7.17 to v3.8 we noticed a huge influx in the number of "Active" queries when opening our app in the Apollo Client Dev Tools.

For context, we use a query in a shared hook that is frequently used but we have taken care to set the fetch policies of the query to be { fetchPolicy: 'cache-first', nextFetchPolicy: 'standby' } so that uses of the query aren't subscribed to cache updates. When a mutation is made, all active queries have to check whether they need to update and re-render and that tanks performance.

I've looked at the in the ./CHANGELOG.md to see if there are any breaking changes but nothing seems to mention nextFetchPolicy: 'standby' effect changing for useQuery.

Is there another recommended way to remove unsubscribe queries and prevent them from being "Active"?

Link to Reproduction

https://codesandbox.io/s/active-queries-3-8-3-cw3jk3?file=/src/index.jsx

Reproduction Steps

• Open the rendered sandbox app in a new window
• Open chrome dev tools with the Apollo Client Dev Tools installed
• View the number of active queries. It reads 1 not 0.
• If you fork the sandbox and revert @apollo/client to 3.7.17 it will read 0 as expected.

[phryneas]

Curious, I don't think that was an intended change.

As for now, you could use @nonreactive, or if you really only want to read from the cache and never want cache updates, just skip using the useQuery hook altogether with something like

function useReadQueryOnce(query, variables) {
  const client = useApolloClient()
  return useMemo(() => {
    return client.readQuery({ query, variables })
  }, [/* adjust your dependency array in a way that makes sense for you*/])
}

[jrans]

Thanks @phryneas for the quick reply!

I'm not sure the useReadQueryOnce is as useful since it requires the query to be in the cache to begin with, which might not always be the case, and so it requires as much effort as making the result available via the context api.

But the @nonreactive directive definitely looks like it could be of some help with this kind of stuff. Hadn't seen the feature before so thanks for sharing the helpful article!

[stephenh]

Oh wow, ironically we'd been using nextFetchPolicy: cache-first for awhile to achieve this:

  const query = use...Query({
    variables: ...,
    fetchPolicy: "cache-and-network",
    nextFetchPolicy: "cache-first",
  });

Per this blog post but it stopped working, probably in 3.8...

But, unlike @jrans , moving to nextFetchPolicy: standby seems to have fixed it for us.

@jrans maybe this was fixed in #11235 which is in 3.8.5?

[phryneas]

@stephenh nextFetchPolicy should generally work again - so if that cache-first worked in the past, it should work again now, too.

[stephenh]

Hi @phryneas ! I used @jrans sandbox to repro that nextFetchPolicy: cache-first still seems broken in 3.8.5; here's a link:

https://codesandbox.io/s/active-queries-3-8-3-forked-kjq3x3?file=/src/index.jsx:0-1894

But I basically added an explicit cache update:

      <button onClick={() => {
        const p = data?.people[0];
        cache.modify({
          id: cache.identify(p),
          fields: {
            name: () => "update",
          }
        });
      }}>update cache</button>

And with nextFetchPolicy: cache-first, the UI still updates, but if I change it to nextFetchPolicy: standup, then it correctly does not update.

[jrans]

My originally reported issue is fixed with the latest version. Thanks team.

@stephenh I'm unsure on what your considering as a bug. The cache-first fetch policy should stay subscribed to cache updates and have the UI update.

[stephenh]

@jrans huh, I guess you're probably right...

The blog post that I linked to, only mentioned "nextFetchPolicy: cache-first" for turning off network requests to refetch the data, not completely disconnect from the cache...

That said, for the 3.7-ish version of Apollo we were on, it definitely /did/ disconnect from the cache, which ngl was confusing, but we were relying on that behavior.

Now that we have standby, which seems new?, specifically for this purpose, cache-first not being "bug compatible" with the older version makes sense.

Thanks!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.