apollo-feature-requests

apollo-feature-requests copied to clipboard

Hi, hope you are doing well.

We were using "apollo-client": "^2.6.4".

After migrating to apollo client 3.2.5 we have issue with merging data in cache. We have some types that are unique for application. And we rquired to write such merge method for every type.

I want to ask you if there is common solution for all types, some prop that will allow us not to write such methods. If there is not such prop, can we contribute to package make such prop?

  cacheRedirects,
  typePolicies: {
    Query: {
      fields: {
        site: {
          merge(existing, incoming) {
            return {...existing, ...incoming};
          }
        },
        userFeatures: {
          merge(existing, incoming) {
            console.log({...existing, ...incoming})
            return {...existing, ...incoming};
          }
        },
      }
    }
  }
});```

@LvovDmitriy Apollo Client 3.3 will support inheritance of type policies, based on possibleTypes information: https://github.com/apollographql/apollo-client/pull/7065. This means you can specify type policies in a shared supertype, and those policies will automatically propagate to any subtypes. You can even make up client-side supertypes that don't exist in your schema, just to take advantage of this feature.

Also, since this style of merge function is very common, you can use the shorthand merge: true instead of writing out the function. This shorthand handles a few important edge cases, and is also faster than a hand-written function, because the cache can skip creating some of the supporting options/helpers: https://github.com/apollographql/apollo-client/pull/6714

Finally, if you're finding it annoying to define merge policies for every field that might contain a particular type of object, in AC3.3 you will be able to define the merge policy for the object type instead: https://github.com/apollographql/apollo-client/pull/7070

Hope that helps!

@benjamn following up on this. Since the default behavior in Apollo 2.x seems roughly equivalent to having merge: true for all types, it would give us more confidence in upgrading to Apollo 3.x if we were able to specify a default merge behavior for our cache rather than having to enumerate it for ALL types in our fairly large schema.

What do you think about this?

After upgrading a long running Apollo 2.x project to 3.4, we are also now maintaining a huge list of types that we apply merge: true, we would benefit from having the ability to have merge: true set as a default for all types, and set it to false for specific types.

We have had several instances where one query will invalidate another query (by overriding an object and effectively deleting some fields the first query was using), and they start firing over and over invalidating the cached data for the other query. The fix is to dig in and find which subfield is not being merged, and adding it to our list of merge: true