Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for generic supertypes #19

Open
brezinajn opened this issue Jul 17, 2024 · 3 comments
Open

Support for generic supertypes #19

brezinajn opened this issue Jul 17, 2024 · 3 comments
Labels
good first issue Good for newcomers

Comments

@brezinajn
Copy link

brezinajn commented Jul 17, 2024

This works fine:

@GraphQLQueryRoot
class Query {
    fun foo(): Int {
        ...
    }
} {

This doesn't:

interface SomeGenericInterface<T>

@GraphQLQueryRoot
class Query: SomeGenericInterface<String>{
    fun foo(): Int {
        ...
    }
}{

There should be no practical difference for the code generator between those two.

@martinbonnin martinbonnin added the good first issue Good for newcomers label Jul 17, 2024
@martinbonnin
Copy link
Collaborator

Hey @brezinajn 👋 Apologies for the delay! We're looking into this together with @oas004 and wondering what the desired outcome was. Do you want SomeGenericInterface to be part of your GraphQL schema?

By default, empty Kotlin interfaces generate GraphQL unions:

union SomeGenericInterface = Query

type Query {
  foo: Int!
}

But it sounds like this is not the desired behaviour here? Did you just want the supertype ignored?

@brezinajn
Copy link
Author

In my optinion the supertype should be ignored.

@martinbonnin
Copy link
Collaborator

Thanks for the reply! Ignoring makes sense. The issue is that by default GraphQL has interfaces and so the processor maps Kotlin interfaces to GraphQL classes:

Kotlin:

sealed interface Node {
    id: String
}
class User(
    override val id: String
) : Node

GraphQL:

interface Node {
    id: String!
}
type User implements Node {
    id: String!
}

We could ignore all non-sealed interfaces but I'm a bit wary this could come as surprising for someone new to the project and expecting an interface to be generated.

What about introducting @GraphQLIgnore? graphql-kotlin has the same and it could be used for other things that interfaces:

@GraphQLIgnore
interface SomeGenericInterface<T>

@GraphQLQuery
class Query: SomeGenericInterface<String>{
    fun foo(): Int = TODO()
 
    @GraphQLIgnore
    fun internalFields(): Int = TODO()
}{
type Query {
    foo: Int!
}

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants