Allow empty object types#1228
Open
benjie wants to merge 1 commit into
Open
Conversation
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
8c40697 to
21a2a8c
Compare
8c13477 to
220e8d4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge first:
Since 2015 we've always required an object type to define at least 1 field. As we continue to explore GraphQL's position in the new AI-world, we realise that we need schema subsets that represents part of a larger interface, in these cases it's sometimes useful to leave in type references without including full definitions of those types:
Here the AI can see a basic schema it can write queries against, but it can also ask to expand the parts of the schema that are relevant to its interests - e.g. books or articles or publishers - without wasting context on things it doesn't care about.
We can make a schema like this valid by including at least one field on each of these types, but it's hard for a tool to know which field(s) to include, and not including fields makes it much more obvious to the LLM that the schema is partial. Making this partial schema itself valid would be helpful for tooling.
AI aside:
type MyMutationPayload { success: Boolean! }is used as a workaround, but it's messy.Related: