Hi all, I wonder if anyone knows how to get hold of the 'type' that you can introspect when doing ... on XYZ
earlier when writing the schema.
I seem to run into a situation where I setup an interface and some implementations.
I have a way to query the interface, and I often end up having to add an enum that I keep up to date with the implementations in order to filter to get a specific type back.
interface SomeInterface {
}
type ImplemntationA implements SomeInterface {
}
type ImplemntationB implements SomeInterface {
}
Query {
getInterfaceThings(filter: SomeInterfaceType) : [SomeInterface]
}
# I have to make sure I maintain this whenever I add a new implementation of SomeInterface
enum SomeInterfaceType {
IMPLEMENTATION_A,
IMPLEMENTATION_B
}
I noticed when doing ... on
it will allow auto complete for each of the implementations suggesting ImplemntationA
and ImplemntationB
so I was wondering if instead of maintaining SomeInterfaceType
there's a way to point to whatever that introspection type is using automagically?Do you mean the __typename
psuedo-field?
I guess the question is whether you can use types as values somehow (“Filter this collection on a type implementing SomeInterfaceType”). As far as I know of thats not something supported by GraphQL. You can get the type name with this pseudo field, but you can’t give the type name back to a query in a way that also enforces that the value you supply is an implementor of SomeInterfaceType
.
You can ofcourse transform Lacinia schemas in arbitrary ways, so you can generate an enum based on this type hierarchy. That said, I wonder whether there is a different schema design that doesn’t require you to pass a type as a value like this.
@hlship Yeah, pretty much, it seems to just be a string when querying, but it also acts a bit more like an enum for autocomplete, so assume there is something in the introspection schema for that. Thanks @lennart.buit, generating the enum programmatically is an interesting idea, worried it might feel a bit magical but I'll have a go, useful to know it's not supported currently. If you have any design ideas I'd be interesting to hear them, it did seem pretty natural to me to want to give a 'wide' query and then let the user narrow it down, specifically as I also have paging, ordering (left off my initial example) which are more useful when able to act across the whole collection.