This is in regards to:
I am intentionally not providing fields to apollo-client. See graphql-deduplicator to understand the motivation. This strategy to reduce the size of the GraphQL response from 1.5MB to just under 100KB.
Whats the reason apollo-client is warning about this in the first place?
Alternatively, suppose that you are planning to remove this feature, does the network middleware allow to intercept the response before it is being interpreted by writeToStore.ts?
A GraphQL result with a shape different to the requested query it's not compliant with the GraphQL specification.
However, perhaps you could use a custom network interface (which reconstructs the result data) so you provide a complete graphql-compliant response to apollo-client.
@cesarsolorzano is right. The main reason we added this feature in the first place is that it helps people much more quickly debug when a manual cache update isn't working as expected. 99% of the time this was because of missing data. This feature took care of it.
If performance is your main concern, then I think you will find that the PR by @abergenw will solve your problem. Once we merge it, you might even be able to provide the non-spec-compliant response to Apollo Client and still have it be inserted into the cache successfully as long as each item has a typename and id.
Presumably, this is the PR thats being referred to https://github.com/apollographql/apollo-client/pull/1675
For some reason I'm seeing this error for queries that shouldn't return the field that's missing. In other words I might get a Missing field CommentsList message for a query that doesn't target that resolver at all.
I'm using Apollo-Link to transform the responses to a format that is better for my app. For instance, I wrap the responses in ImmutableJS structures, add some fields and remove some others. Because I remove the __typename from the response data, I get this warning. Is there any way to transform the response without triggering these warnings?
Most helpful comment
For some reason I'm seeing this error for queries that shouldn't return the field that's missing. In other words I might get a
Missing field CommentsListmessage for a query that doesn't target that resolver at all.