Optional Apollo Client configuration to make type policies in the cache merge by default

[nlokare]

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 apollographql/apollo-client#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.

[joelmukuthu]

I landed here as well, but after reading through apollographql/apollo-client#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).

[benjamn]

@nlokare @joelmukuthu Configuring merge policies will be easier (less repetitive) in Apollo Client 3.3, thanks to apollographql/apollo-client#6714, apollographql/apollo-client#7070, and apollographql/apollo-client#7065.

[jpvajda]

Given all of these related PRs are merged, I'm opting to close this out now. Thanks for the feedback!