Apollo-client: client.readQuery() does not throw when cache is entirely empty

[ctavan]

Intended outcome:
The documentation at https://www.apollographql.com/docs/react/caching/cache-interaction/#writequery-and-writefragment states:

If your cache doesn't contain all of the data necessary to fulfill a specified query, readQuery throws an error. It never attempts to fetch data from a remote server.

I would expect client.readQuery() to _always_ throw an error, if it cannot fulfill the given query. This _was_ the case with apollo-client 2.6.10.

Actual outcome:
With apollo-client 3.1.0, on an entirely empty cache, i.e. in a state where _no_ real graphql query has been fired yet, client.readQuery() just silently returns null. The lines which seem to cause this behavior are the following: https://github.com/apollographql/apollo-client/blob/8ab164bbfa8b7e1eea6b4f33cb9a63af0101c053/src/cache/inmemory/inMemoryCache.ts#L110-L112

If the store doesn't have the ROOT_QUERY property yet, then readQuery will silently return null.

How to reproduce the issue:
A minimal reproduction can be found here: https://github.com/ctavan/react-apollo-error-template/tree/read-query-on-empty-store

A workaround is to set some placeholder value beforehand, e.g. like this:

apolloClient.writeQuery({
  query: gql`
    query RootQueryInit {
      rootQueryInit
    }
  `,
  data: {
    rootQueryInit: true,
  },
});

Versions

  System:
    OS: macOS 10.15.6
  Binaries:
    Node: 14.8.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.7 - /usr/local/bin/npm
  Browsers:
    Chrome: 85.0.4183.83
    Edge: 79.0.309.65
    Firefox: 79.0
    Safari: 13.1.2
  npmPackages:
    @apollo/client: ^3.1.0 => 3.1.0

[ptrwllrt]

We've running in the same behaviour, also if there is any data it doesn't throw. Our usecase is slightly different as we're using this behaviour on SSR to determine if the query got a response and would return a 404 flow instead of the resouce page.

It's seams that getting null for readQUery is going to be a standard behaviour in the comming releases.
https://github.com/apollographql/apollo-client/pull/7098/files

[ctavan]

@ptrwllrt I was still using the workaround described above in my code base.

However thanks for pointing me to this issue again. I have now tried @apollo/[email protected] that includes the linked PR and simply check for a null return value of readQuery() instead of catching an error.

So from my point of view this issue can be closed.

[benjamn]

@ctavan I'm very glad to hear you're okay with us going in the opposite direction (returning null consistently instead of throwing)! I am continually surprised by how much JavaScript developers dislike handling exceptions (see for example https://github.com/apollographql/apollo-feature-requests/issues/1), but for readQuery I agree it's more convenient to return null consistently (as explained in #7098).

[ctavan]

@benjamn I actually don't really care if readQuery throws or returns null when the cache is empty. The only issue I had was that the behavior pre 3.3 had become inconsistent compared to 2.6: It sometimes threw and sometimes just returned null, depending on whether the store was entirely empty or not.

With this inconsistency removed I'm totally fine with reacting to null results instead of catching an error.