[benjie]

Since 2015 we've required selection sets to contain at least one field; however it's always been possible to have an empty object returned:

type A { a: Int }
type B { b: Int }
union U = A | B
type Query { u: U }

query {
  u {
    ... on A { __typename }
  }
}

Here, if u returns type B the result will be {"data":{"u":{}}} - i.e. an empty object.

GraphQL clients are getting smarter and smarter, and it's common to have client-side extensions such as Apollo's @client, Relay Resolvers or @mock'd fields. In all of these cases, any selections of these fields need to be removed before the document is sent to the server. But what happens when all the fields in the selection set are to be removed?

  query LaunchDetails($launchId: ID!) {
    launch(id: $launchId) {
      isInCart @client
      site @client
    }
  }

There are many options (add __typename, remove launch, throw error, ...), but the safest solution is to allow the selection set to be empty. Hence, this PR.

• Fixes [RFC] allow empty selections #674

[netlify]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	e10dca1
🔍 Latest deploy log	https://app.netlify.com/projects/graphql-spec-draft/deploys/6a9a9c8ff4b52d0008c09281
😎 Deploy Preview	https://deploy-preview-1227--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.

[martinbonnin]

👍

[jerelmiller]

💯

[magicmark]

nice :)

[benjie]

I believe this is ready to merge, pending @yaacovCR's feedback on the GraphQL.js PR:

• spec change: allow empty selection sets graphql-js#4852

[yaacovCR]

If we're going to merge this, I think we can takeoff the experimental label on the associated PR?

[martinbonnin]

If we're going to merge this, I think we can takeoff the experimental label on the associated PR?

Excellent observation @yaacovCR. We can even probably drop the parameter altogether?

[martinbonnin]

I made another version of the PR if we decide to expedite this:

• with experimental flag
• without experimental flag

My preference goes to "without experimental flag". Less complexity is better.

[benjie]

I personally would keep the flag until next semver major, even if you default to enabling the feature. Reason: their security systems might not be set up to handle queries like this; consider:

{
  user {
    a: friends {}
    b: friends {}
    c: friends {}
  }
}

if they're using complexity cost that multiples expected list length by selection set cost, and selection set cost is zero because there's no fields (previously not possible), it might have an impact on their security. (The IBM cost spec does not suffer from this AFAIK, but there are lots of models of query cost in the wild.)

There may be other such concerns that we're not yet aware of, so giving people a way to opt out until v18 does not seem unwise.

[martinbonnin]

giving people a way to opt out until v18 does not seem unwise.

Works for me. All in all:

• drop experimental: experimentalEmptySelectionsSets -> allowEmptySelectionSets
• default to true
• make it deprecated
  ?

I have updated the PR in that direction. Let me know if something else is preferred.

[benjie]

We'll merge this during the secondary WG on Thursday 17th unless anyone has reservations (express them now!)