Query with embedded fragment returns an empty object on cache miss instead of null

[jebonfig]

This is a new issue in beta.53 as a result of c810713

With this code:

typePolicies: {
  Query: {
    fields: {
      pokemon(existingData, { args, toReference }) {
        return existingData || toReference({ __typename: 'Pokemon', id: args?.id });
      }
    }
  },

...

const PokemonFields = ` 
  fragment PokemonFields on Pokemon {
    id
    number
    name
    classification
    types
    resistant
    weaknesses
    fleeRate
    maxCP
    maxHP
    image
  }`

// FRAGMENT BASED QUERY
  
let FRAGMENT_POKEMON_QUERY = gql`
  ${PokemonFields}
  query pokemon($id: String) {
    pokemon(id: $id) {
      ...PokemonFields
    }
  }
`;

Intended outcome:

1. When using a read type policy and a query containing a fragment with a cache* fetchPolicy, when the cache misses, return null for the result instead of an empty object.

2. most likely directly related to 1, cache-first needs to make a network call to fetch the data if the initial cache search missed.

Actual outcome:

If cache-only, or cache-and-network, the returned pokemon is an empty object on renders until the cache hits.

If cache-first and the cache missed, the returned pokemon is an empty object on all renders, and a network call never gets made.

If the query does not use a fragment, or the fetchPolicy is network-only, the returned pokemon will be null on all renders until the cache hits or the network call returns with data. I believe this is the expected behavior.

As a result of the above behavior, depending on the fetchPolicy and whether a fragment is embedded, the result object can now be either null, or an empty object.

How to reproduce the issue:

Repro here: https://github.com/jebonfig/react-apollo-error-pokemon

Versions

  System:
    OS: macOS High Sierra 10.13.6
  Binaries:
    Node: 11.2.0 - /usr/local/bin/node
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 83.0.4103.61
    Safari: 13.1.1
  npmPackages:
    @apollo/client: ^3.0.0-beta.53 => 3.0.0-beta.53 

[benjamn]

@jebonfig This should be fixed in the latest beta (-bets.54). Thanks for catching this regression so quickly, and sorry for any inconvenience it caused.