Fork me on GitHub
#graphql
<
2021-06-15
>
Daniel Stephens08:06:11

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?

hlship17:06:23

Do you mean the __typename psuedo-field?

đź‘Ť 2
Lennart Buit17:06:36

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.

Daniel Stephens21:06:38

@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.