[DaleSeo]

Follow up to:

• Allow empty object types #1228
• Allow interfaces with no fields, unions with no members #1229

Today, an input object type must define at least one input field. This proposal removes that requirement, making input Filter {} a valid definition. The goal is to bring this to the Nov 5 Working Group as RFC 1.

The motivation comes from the Schema Search RFC (graphql/ai-wg#187). It describes a service that returns a valid subset of its schema as SDL in response to a natural language query. That subset may need to include an input object required by an operation, even when the query does not involve any of its fields:

type Query {
  issues(filter: IssueFilter!): [Issue!]!
}
input IssueFilter {}
type Issue {
  title: String!
}

Under the current rule, the slicer has to either drop the issues field, hiding the entry point, or keep an arbitrary input field. This change lets the slice retain the reference and allows the model to request IssueFilter later.

It also removes one more reason a schema with all deprecated elements removed can become invalid, as mentioned in #1228 (comment).

GraphQL.js implementation: graphql/graphql-js#4923, graphql/graphql-js#4934

[netlify]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	c3783da
🔍 Latest deploy log	https://app.netlify.com/projects/graphql-spec-draft/deploys/6ae354eb6b058853340afa93
😎 Deploy Preview	https://deploy-preview-1249--graphql-spec-draft.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[benjie]

When thinking about what can be left out of an input type, all required fields must be retained. Consider:

input Foo {
  a: Int
  b: Int!
  c: Int = 1
  d: Int! = 1
  e: [Int!]
  f: [Int!]! = []
}

this could compress down to:

input Foo {
  b: Int!
}

but representing it as an empty input object would be invalid, a value could not be fed to that argument that the underlying schema (with all the input fields) would accept.

---

(Solved: feedback on PR description)

Incidentally the argument around your example:

type Query {
  issues(filter: IssueFilter): [Issue!]!
}

Under the current rule, the slicer has to either drop the issues field, hiding the entry point, or keep an arbitrary input field.

doesn't quite hold because it can be mapped by dropping the filter argument:

type Query {
  issues: [Issue!]!
}

Maybe you meant issues(filter: IssueFilter!): [Issue!]!?

[benjie]

IIRC¹, Lee has expressed a preference that we distinguish these for other types; mapping to input objects:

# Valid empty input object type
input Empty {}

# Declared but incomplete input type - awaiting field declarations
input Empty

With this, you might also need to allow input extensions to contain * rather than + fields.

Footnotes

1. My memory of this is hazy though, so I'll need to go back through the notes/videos to see exactly what was said. ↩

[DaleSeo]

Lee's comment in #1228 (comment) and PR #1245 got me thinking that we should allow {} as well, not {} only. 😅

Now I realize my reading was wrong. I've dropped the "equivalent" sentence and the braceless example, and taken your validation wording.

The same question applies to the sibling PRs, so I left notes there to make sure all three line up.

[martinbonnin]

With this, you might also need to allow input extensions to contain * rather than + fields.

@benjie can you ellaborate? Since InputObjectExtensions reuses the InputFieldDefinitions grammar rule, both input definitions and extensions should have *?

InputObjectTypeExtension :
- extend input Name Directives[Const]? InputFieldsDefinition
- extend input Name Directives[Const] [lookahead != `{`]

InputFieldsDefinition : { InputValueDefinition\* } // * proposed in this PR

[benjie]

I said "might" because I didn't check the grammar rules for extensions and wasn't sure if they might still use + via a different mechanism (e.g. I didn't check if they did extend input Name Directives[Const]? { InputValueDefinition+ }). Since they use the same grammar rule that has already been adjusted, InputFieldsDefinition, no action necessary.

[benjie]

I think something went wrong with GitHub, some of the comments from my review posted but others remained "pending". I've submitted the review again, but now it looks like there might be duplicates... I'm not going to delete them in case that causes more headaches 😅