Support usage with GraphQL query responses

When using this library to add type information to the anticipated structure of GraphQL queries to Contentful, I found that this library doesn’t quite support my use case.

There are two exported interfaces for each of the Contentful models. The IModelNameFields and IModelName interfaces. When I query with GraphQL, the model of the data is comprised entirely of interfaces matching the IModelNameFields signatures, rather than the IModelName interfaces. For modes that don’t have any references, this is fine because I can simply declare that the GraphQL query structure will contain interfaces using IModelNameFields. However, if there is a relation where one model references another, the reference points to an IModelName interface.

For example, say you have a model Blog with a relation to a Comment model. If I do a GraphQL query for all Comments, then I’m okay because I can use the ICommentFields interface. However, if I do a GraphQL query for Blogs, and I provide the IBlogFields interface, the interface will have a relation to IComment, which won’t match the structure of the object I get back from GraphQL.

Might it be possible for this library to support my use case? As it stands now, I will need to override all of the relations for my models in the generated interfaces. This is significantly less work than maintaining entire interfaces myself, but I’d prefer for the interfaces generated to match 1:1.

Thanks!

[davidhousedev]

@sonia-y we’ve since migrated to use graphql-code-generator too and I really like that everything is nullable because of preview environments. We found that we were encountering many type errors in preview environments (where validation hasn’t run yet). I suppose if you only read published data and you require everything, the utility is lower 😃.

[sonia-y]

Actually facing a similar issue… originally was using graphql-code-generator to generate all of the contentful types, but the issue with Contentful’s GraphQL schema is that all fields are nullable/optional, which doesn’t allow us to really leverage TS very well since we need to do null-checks everywhere.