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

Add support for extending Scalar, Union, Enum, and Interface types in SchemaParser #552

Open
3 tasks done
rropp5 opened this issue Jul 22, 2021 · 1 comment
Open
3 tasks done

Comments

@rropp5
Copy link

rropp5 commented Jul 22, 2021

I want to suggest an idea and checked that ...

  • ... to my best knowledge, my idea wouldn't break something for other users
  • ... the documentation does not mention anything about my idea
  • ... there are no open or closed issues that are related to my idea

Description

According to the June 2018 GraphQL spec, the following types may be extended in a GraphQL schema:

  • Scalars
  • Objects (type in SDL)
  • Interfaces
  • Unions
  • Enums
  • InputObjects (input in SDL)

The kotlin.graphql.kickstart.tools.SchemaParser.kt class currently supports extensions of Objects and InputObjects but it does not support extensions for Scalars, Unions, Enums, or Interfaces. The result is that extensions of these types are not respected when constructing the corresponding GraphQLTypes.

This new feature could be modeled after the existing behavior in the SchemaParser that currently separates ObjectTypeExtensionDefinitions and InputObjectTypeExtensionDefinitions.

Add logic to SchemaParser to treat ScalarTypeExtensionDefinitions, UnionTypeExtensionDefinitions, EnumTypeExtensionDefinitions, and InterfaceTypeExtensionDefinitions similar to ObjectTypeExtensionDefinitions and InputObjectTypeExtensions.

Use Cases

Support extending Scalar, Union, Enum, and Interfaces types throughout a schema.

Note: This opportunity for enhancement was discovered while attempting to extend a union type. I have not confirmed the behavior for Scalar, Enum, or Interface types but have included those types in this issue based on code inspection of the SchemaParser class.

Consider the following SDL:

union FooBar = Foo | Bar

extend union FooBar = Baz

The expectation is that FooBar would resolve to Foo | Bar | Baz. However, under the current implementation it resolves to Baz.

@Sceri
Copy link

Sceri commented Jul 25, 2021

I can confirm that extending the interfaces doesn't work either. As a result, some fields will be missing in the interface definition, which creates bugs at runtime. It would be nice to throw an exception for features that are currently not supported when parsing the schema.

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

No branches or pull requests

2 participants