You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's say I have a schema for some translated content with a common interface for entries:
interface Entry {
id: ID
slug: String
translations: [Entry]
}
type Page implements Entry {
id: ID
slug: String
translations: [Page] # Page implements Entry, this should be ok
}
In graphql-js this errors, saying the translations on Page should be of type [Entry]. Since Page implements Entry and translations of a Page will only ever be Pages, this seems ok to me.
Tried the same with union types with the same result. It's not a disaster, I can widen it to the interface type and use a type fragment in queries, but it seems a little unwieldy.
Am I missing a reason why it's not valid to narrow down an interface type when implementing an interface which specifies a field of an interface type? (uh, sorry, can't make that sentence any simpler)
The text was updated successfully, but these errors were encountered:
Closing this since it was fixed in the Dec spec and has since been implemented in graphql-js!
We refer to this as covariant interface implementation. That is you have implemented the interface, but you just supplied a covariant type (Page is an Entry) instead of an invariant type (must be Entry and only Entry).
We started with invariant interface implementation mostly as a simplifying force. Adding this kind of type system rule can add complexity to the rest of the system by introducing new kinds of cases that validation needs to consider, but in this case the complexity added was not untenable and it is worth it to enable this kind of query.
Let's say I have a schema for some translated content with a common interface for entries:
In graphql-js this errors, saying the translations on
Page
should be of type[Entry]
. SincePage
implementsEntry
and translations of aPage
will only ever bePage
s, this seems ok to me.Tried the same with union types with the same result. It's not a disaster, I can widen it to the interface type and use a type fragment in queries, but it seems a little unwieldy.
Am I missing a reason why it's not valid to narrow down an interface type when implementing an interface which specifies a field of an interface type? (uh, sorry, can't make that sentence any simpler)
The text was updated successfully, but these errors were encountered: