I want to use graphql @include
and/or @skip
directives for compatibility between frontend and backend.
Assume backend and frontend have a differing schema:
backend:
type Foo {
someOldProp: Int!
}
frontend:
type Foo {
someOldProp: Int! @deprecated(reason: "Use someNewProp instead")
someNewProp: Int!
}
now in frontend I define following fragment:
fragment FooFragment on Foo {
someOldProp @skip(if: $hasNew)
someNewProp @include(if: $hasNew)
}
When passing $hasNew
as false
in a query, the fragment should be resolved as:
fragment FooFragment on Foo {
someOldProp
}
which would be a valid fragment to be used with the backend schema above.
However, even in this case our graphql service complains about
Cannot query field 'someOldProp' on type 'Foo'
.
Reading the spec, it's not totally clear to me whether this is a bug in our graphql implementation (which should not attempt accessing a field when @include
/@skip
exclude the field),
or whether these directives are only to be used when all underlying fields are available, but when a subset of them is not needed by the client.
In the latter case a graphql implementation would be free to query a field at first, and only erase it before handing it to the client which would explain the error-message.
Does anyone have some insight?