Wrap auto-completed list input values with square brackets if required

[KyleAMathews]

In Gatsby's connections, you can add a sort input like the following:

allMarkdownRemark(sort: { fields: [frontmatter___title], order: DESC}) {
  edges {
    node {
      id
    }
  }
}

But in graphiql, it doesn't enforce that fields must be an array so people regularly complain sorting is broken as they just add a field in the UI and then when they try to copy that into a project it won't work.

Is there a reason graphiql is like this? It seems to be casting the single values to an array which is why it seems to work.

[coreyward]

+1 Currently Relay will cast a single value to a string; graphiql's deviation from this causes incompatibilities.

[OlegIlyenko]

If I understand what you are describing correctly, then this aspect is covered by the GraphQL spec:

If the value passed as an input to a list type is not a list and not the null value, it should be coerced as though the input was a list of size one, where the value passed is the only item in the list. This is to allow inputs that accept a “var args” to declare their input type as a list; if only one argument is passed (a common case), the client can just pass that value rather than constructing the list.

In other words, it is ok to skip list syntax (e.g. [...]) if list has only one element.

[coreyward]

@KyleAMathews Is Gatsby doing something custom on top of Relay or is this a bug with Relay? I don't know enough to tell (couldn't find the intermediary files produced by Relay in my .cache).

[acao]

@coreyward so, gatsby is not using relay, they have their own graphql schema implementation on top of graphql-js.

what @OlegIlyenko's pointing out here is a valid bug incodemirror-graphql's implementation of the official GraphQL spec. and it's our job to adhere to the spec, so this is a bug that would impact relay's IDE implementation as well as many others.

[benjie]

I couldn't find an example of this in the SWAPI API, so I went to GitHub's API where they have the marketplaceCategories field which accepts a parameter called includeCategories which is a list of strings. https://developer.github.com/v4/explorer/

Issuing this query:

{
  ai: marketplaceCategories(includeCategories: "ai-assisted") {
    name
    slug
  }
  aiOrChat: marketplaceCategories(includeCategories: ["ai-assisted", "chat"]) {
    name
    slug
  }
}

against the GitHub API correctly returns this result:

{
  "data": {
    "ai": [
      {
        "name": "AI Assisted",
        "slug": "ai-assisted"
      }
    ],
    "aiOrChat": [
      {
        "name": "AI Assisted",
        "slug": "ai-assisted"
      },
      {
        "name": "Chat",
        "slug": "chat"
      }
    ]
  }
}

As @OlegIlyenko correctly points out the "Input Coercion" section of TypeSystem > List in the GraphQL spec allows for a single list item to be specified without using the brackets. GraphiQL seems to support this just fine, so I don't think we have a bug here.

That said, having the auto-complete automatically insert list wrappers around an option selected from a list type would be a welcome addition as sometimes people rely on auto-complete rather than the docs and do not realise that a list is possible in a particular position.

[acao]

i was able to reproduce the error the other day, its a bug

[benjie]

Can you expand on what the error/bug is, please?

[acao]

given @OlegIlyenko 's point re: the spec, do we feel this is indeed a bug?

@coreyward do you feel this behavior is to spec? or is there a way we can support the spec and multiple expectations here?

[amanprateek123]

@acao I want to contribute in open source in graphql. How can I start?

[acao]

this is a place where additionalInsertText is used. we would add it to graphql-language-service-interface in the completion response for getAutocompleteSuggestions, and then handle that information in graphql-language-service-interface when normalizing the completion data in the utility at the end of MessageProcessor.ts.

vscode-json-languageservice has an excellent implementation of this that we can learn from, though their needs for insertText might be more complicated than ours.

our most important insertText is this feature by far, the reference example shows how they do this for for json arrays and objects using json schema. I already can show how to filter completion items to return the insertText when and where we need, just need to finish normalizing the insertText information across the service layers