Apollo-feature-requests: Optional Apollo Client configuration to make type policies in the cache merge by default

Created on 18 Sep 2020 · 2Comments · Source: apollographql/apollo-feature-requests

Hi,

After upgrading our app to Apollo Client 3, we've run into issues with the data object on a query returning null, despite seeing successful network requests with resolved data. After some thorough debugging, we were able to identify that there was an issue with cached objects requested in two different queries, with one query requesting a subset of properties for that object requested with a larger set of properties in another.

Assume customObject is of __typename: CustomObject
ex:

query myQuery {
  myQuery {
    values {
      customObject {
        id
        name
        details {
          propOne
          propTwo
        }
      }
    }
  }
}

vs.

query myOtherQuery {
  myOtherQuery {
    objects {
      customObject {
        id
        name
        details {
          propOne
        }
      }
    }
  }
}

Without an explicit type policy to merge CustomObject.details, the second query will result in the CustomObject:[id] object being overwritten in the cache, resulting in data set to null when the other query requests the superset of values on CustomObject:[id].

Considering the design of our schema and the cross-team use-cases for querying for common types across the graph, this problem will continue to arise as developers request varying properties of a given CustomObject, for example. Having the option to configure the Apollo Client 3 cache with a merge: true for all by default would be greatly appreciated and extremely useful at preventing hard-to-track bugs. Similarly, I think this is more in line with the underlying principles of GraphQL, by allowing developers to request the exact properties necessary for a given component/screen/etc without worrying about the mechanics of how this is handled in the cache.

This issue https://github.com/apollographql/apollo-client/pull/5603 provides some reasoning for the decisions implemented, but I respectfully think it overlooks the use-case I illustrated and can complicate the development process.

Thanks for the consideration.

Source

nlokare

👍2

Most helpful comment

I landed here as well, but after reading through https://github.com/apollographql/apollo-client/pull/5603 I agree with the decisions taken there. In your example, since details is not an indentifiable type it makes sense that you have to provide an implementation of how to merge the field.

However, it would be nice for Apollo Client to print out a warning when it encounters (and replaces) object fields that are not identifiable to reduce surprises and help with debugging (not sure if a warning is printed out already).