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

Issue with Spread Syntax and Field Return Type Override in GraphQXL #60

Open
ruchib30 opened this issue Nov 26, 2024 · 0 comments
Open

Comments

@ruchib30
Copy link

We are using interface hierarchies extensively in our GraphQL schema and encountered an issue with GraphQXL when attempting to override a field's return type in a type implementation. According to the GraphQL specification, it is valid for a field in an implementing type to override the return type of the interface field with a more specific type, provided the new type implements the original return type. However, GraphQXL fails to compile when the spread syntax (...) is used, even though this is spec-compliant.

Example Schema:

# Definition of an interface
Interface I1 {
}

# Definition of a type that implements the interface
Type T1 implements I1 {
}

# Interface with multiple fields, including a field of type I1
Interface Base {
  field: I1
  # many more fields
}

# Implementation without spread syntax - This works
Type BaseType implements Base {
  field: T1 # Valid as T1 implements I1
  # all other fields of interface Base are manually copied
}

# Implementation with spread syntax - This fails to compile
Type BaseType implements Base {
  ...Base
  field: T1 # Valid as T1 implements I1 but fails compilation
}

Expected Behavior:
The schema should compile successfully, as overriding field with T1 is valid per the GraphQL spec, and the spread syntax should allow inclusion of all other fields from the Base interface without redundancy.

Observed Behavior:
GraphQXL fails to compile when the spread syntax is used, forcing us to manually copy all other fields from the Base interface to ensure compatibility.

Request you to look into this and provide support for above syntax. This would greatly improve maintainability for schemas leveraging interface hierarchies.

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

No branches or pull requests

1 participant