Could Apollo Client send `.id` fields in selection sets?

Feedback
,
1

Howdy! I have a “could this work” question for Apollo Client:

We’re currently trying to set up a cache normalization strategy for our clients. The default strategy of “use .id if available” (Caching in Apollo Client - Apollo GraphQL Docs) works great! We should just use that everywhere - (although I think this isn’t the case on mobile?)

Anyway the problem as I understand it is - this requires developers to remember to include .id in their selection sets - otherwise how does Apollo Client know how to cache it?

A similar problem exists with “which member of a union are you” - the solution to which is __typename, and Apollo automatically adds this to all selection sets in all queries sent.

Would it be a terrible idea to have Apollo Client similarly send .id (if available on the type)? A big downside is that this would require knowledge of the schema, to know if it’s available or not, and hence some state (a build artifact) or user supplied configuration - so I realize this isn’t a trivial change. Has this been discussed at all?

(I know the alternative is to use type policies dataIdFromObject to “teach” Apollo how to uniquely identify an object, but that’s something we’d have to duplicate on all platforms and other places in our infra that need to understand how to uniquely identify a type. Our ideal plan would be to encapsulate it all into .id, and have that be the source of truth.)

Thanks!

2

I’ve been using eslint-plugin-graphql. The Required Fields Validation allows you to require that the id field is queried in order for eslint to pass. You do need access to the backend graphql schema during development in order for this to work, but it’s a build-time check so it doesn’t increase your bundle size at all.