Apollo-client: [3.0] Documentation and Behaviour around updating the cache from mutation response makes no sense

[breathe]

This documentation and the associated behavior makes no sense:

https://www.apollographql.com/docs/react/v3.0-beta/data/mutations/#updating-a-single-existing-entity

1. It appears that apollo is _only able_ to update a single entity in response to a mutation. There is no explanation for _why_ this limitation exists ... Its hard for me to understand why apollo couldn't iterate over the mutation response, find all the 'id's, and mutate all cache entries corresponding to those id's ...

If there is a reason why a mutation response which contains updates to three entities each identified by ID couldn't automatically produce an update to the apollo cache -- it is not obvious what this reason is ... I think this limitation _deserves_ to be explained in an accurate way -- because if there's a good reason for it -- it seems very subtle and probably very important to understand _why_ in order to understand how I should be using apollo client ...

1. Suppose you have a mutation like this:

{
 mutation SomeMutation(...) {
  parent {
      id
      child {
         id
         property
     }
   }
  }
}

Even with the type corresponding to child added to typePolicies with { keyFields: false }, the cached value of child will not be updated as part of the update to parent.

It seems the _presence_ of a field named id is enough to make it impossible to automatically update multiple identifiable elements based on a single mutation response, even when denormalization is not involved ...?

This is very annoying and unnecessarily complicates migration from apollo-client 2 -- which afaict doesn't limit updates from a mutation response to a single entity ...

I very much dislike the limitation of mutation response to a single entity, having designed my whole graphql api to work well with apollo client 2 where I frequently return sets of entities in my mutation responses -- arbitrarily nested as needed.

If the change isn't explained in a way that I can understand, I will probably be forced to abandon apollo client because I just don't understand why this design decision was taken and feel like I must be doing something incredibly wrong given _how much_ my thought process wants me to do this ...

[benjamn]

@breathe I agree with you that updating multiple entities with one mutation response should be possible. In fact, if I'm honest about my personal views, I think GraphQL servers should attempt to describe any/all relevant changes in their mutation responses, in a way that can be consumed automatically by the client, without any manual updating of the cache. Having to think about all the possible consequences of a mutation severely limits the reactivity of the application.

I didn't write these particular docs, and I have to admit I'm not sure why things wouldn't work the way you expect. Maybe there's a simple fix, but (if so) it's definitely a problem that it's not more obvious.

Can you put together a small reproduction using

git clone --branch ac3 [email protected]:apollographql/react-apollo-error-template.git

when you have a chance? I know this sounds like an extra step, but it would give us a very clear way of knowing whether we've solved your problem, so we won't need as much back-and-forth after we come up with an initial solution/recommendation.

[breathe]

In fact, if I'm honest about my personal views, I think GraphQL servers should attempt to describe any/all relevant changes in their mutation responses, in a way that can be consumed automatically by the client, without any manual updating of the cache. Having to think about all the possible consequences of a mutation severely limits the reactivity of the application.

@benjamn i agree and that was actually the way I've been designing things in my application. I was surprised when I tried to upgrade to apollo client 3 beta that I couldn't achieve this anymore.

I will try and get create an example project to demonstrate the issue when I get a chance some time in the next few days.

Thanks,

[darkbasic]

I think the whole point about this is standardizing the return type from the server: if we succeed in doing so it could be possibile even to automatically invalidate queries when an entity gets deleted.

[hwillson]

This should be addressed in the new documentation. You can follow along in https://github.com/apollographql/apollo-client/pull/6429. Thanks!