Using ApolloClient - the client is making a GraphQL request to Contentful for a reasonably complex query (altho only 1021 query cost) - it is a 'page' with sections of various types, and some of the section entry types can have a collection of 'items'. The 'items' are queried for just their __typename
and their sys
object - so that they can be requested directly and fully in due course.
The request returns the correct data (see first image), but if I log the response from ApolloClient query immediately after the resolution, the sys object is missing (see second image).
I'm logging a parsed JSON string of the resolved response, so I'm confident it's not that the object is being mutated further down the line - if it's being mutated, it must be somewhere in the Apollo client.
The sys object is correctly included for other items at the same level, with the same content type, elsewhere in the page response.
It's not practical to make a reproducible example because of the level of integration required, so I guess my question is: why might this be happening?
The solution is frustratingly simple (aren't they always):
I have a fragment matcher that requests the Contentful schema to generate the full map of available unions and interfaces. This is by default pointed at the master
Contentful environment. It's based on the documentation here:
https://www.apollographql.com/docs/react/v2/data/fragments/#fragments-on-unions-and-interfaces
On this dev branch I was using a clone Contentful environment to test this new type, but the schema generator was by default still pointed at master
, which meant that the type didn't exist in the stored schema. Once updated to reflect the target environment, it's working as expected.