useQuery doesn't seem to use defaultOptions in 3.5

Hey, excited about the v3.5.4 release! RedwoodJS uses Apollo Client as its default GraphQL client. (Our implementation lives here: https://github.com/redwoodjs/redwood/blob/main/packages/web/src/apollo/index.tsx.) I recently moved the useQuery configuration up to the client, using defaultOptions.watchQuery as the docs say here (here’s the PR: https://github.com/redwoodjs/redwood/pull/3747). This was working great in v3.4.x but seemed to have broken in v3.5.x, as in useQuery doesn’t seem to care about the client’s defaultOptions.watchQuery.

Intended outcome:

Setting defaultOptions.watchQuery in Apollo Client configures all useQuery hooks.

Actual outcome:

useQuery hooks seem to ignore the defaultOptions.watchQuery configuration set in Apollo Client.

How to reproduce the issue:

Repo with reproduction (the readme has steps to reproduce): https://github.com/jtoar/apollo-client-default-options. And video walkthrough showing the behavior I’m seeing:

https://user-images.githubusercontent.com/32992335/142956267-8f845c71-dae5-428e-aedd-afa385205bb4.mp4

Versions

  System:
    OS: macOS 12.0.1
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: 1.22.17 - ~/.nvm/versions/node/v16.13.0/bin/yarn
    npm: 8.1.3 - ~/.nvm/versions/node/v16.13.0/bin/npm
  Browsers:
    Safari: 15.1

[gjvoosten]

@brainkim I’ll explain our situation which does have the problem that queries are not executed because the defaultOptions are ignored, and which is solved by my patch above. Our client (which is provided through an ApolloProvider) has:

  const client = new ApolloClient({
    …,
    defaultOptions: {
      query: {
        fetchPolicy: "no-cache"
      },
      watchQuery: {
        fetchPolicy: "no-cache"
      },
      mutate: {
        fetchPolicy: "no-cache"
      }
    },
    fetchOptions: {
      credentials: "same-origin"
    }
  })

We have Edit pages that retrieve an object through useQuery, then mutate it, then redirect to the Show page, where the object is retrieved again through useQuery. We don’t use caching in the client, as the object might have been edited by anyone at anytime, so we always need a fresh copy from the server. With @apollo/client v3.4.17, the Show page does another network request, picking up the changes. With v3.5.5, the Show page does not do another query, and we get the outdated object. When debugging this, it was clear to me that the defaultOptions were ignored (hence my proposed solution). Only if for v3.5.5 I change my query to useQuery(q, { fetchPolicy: "no-cache" }), i.e. explicitly set a policy on each request, do I see network requests flying again. With my patch above (let’s call that v3.5.6-SNAPSHOT), I can resort back to just useQuery again and experience the same behaviour as with v3.4.17. So I maintain that this is a bug in v3.5 that needs to be fixed. Please correct me if I’m wrong, but our tests pass with v3.4.17 and fail with v3.5.5, for the reasons outlined above.

[gjvoosten]

@brainkim At quick glance, something like this should fix it (diff against current main branch):

diff --git a/src/react/hooks/useQuery.ts b/src/react/hooks/useQuery.ts
index bdabb3e72..a5ea139ad 100644
--- a/src/react/hooks/useQuery.ts
+++ b/src/react/hooks/useQuery.ts
@@ -10,6 +10,7 @@ import {
   DocumentNode,
   TypedDocumentNode,
   WatchQueryOptions,
+  mergeOptions,
 } from '../../core';
 import {
   QueryHookOptions,
@@ -28,6 +29,9 @@ export function useQuery<
 ): QueryResult<TData, TVariables> {
   const context = useContext(getApolloContext());
   const client = useApolloClient(options?.client);
+  if (client.defaultOptions?.watchQuery) {
+    options = mergeOptions(client.defaultOptions.watchQuery, options as any);
+  }
   verifyDocumentType(query, DocumentType.Query);
   const [obsQuery, setObsQuery] = useState(() => {
     const watchQueryOptions = createWatchQueryOptions(query, options);

Tested with my own application and it appears to work. Probably needs some tests, and someone with more in-depth knowledge of Apollo Client should go over it to see if this is the correct approach.