allow transforming query text before passing it to `graphql-language-service-interface`

I’d like to be able to append to editor’s query text (or more generally transform it) before sending it to graphql-language-service-interface.

Motivation

In https://github.com/gatsbyjs/gatsby we allow supplying fragments that users can use freely in their queries (we transform queries and attach used fragment definitions before query execution with the help of relay-compiler). This works well in queries to users write in their source code, but doesn’t work currently in graphiql because those 3rd party fragments are not in document and codemirror-graphql/lint report errors (missing fragment definitoins) and codemirror-graphql/hint also can’t provide autocompletion hints for those fragments it doesn’t know about.

Proposed design

Allow passing extra option to addons - for example transformQueryText function (that will default to identity transform if not specified), that will be exucuted before passing query text to graphql-language-service-interface functions (getDiagnostics for lint / getAutocompleteSuggestions for hint):

CodeMirror.fromTextArea(myTextarea, {
  mode: 'graphql',
  lint: {
    schema: myGraphQLSchema,
    transformQueryText: queryText => doSomethingWithQueryText(queryText)
  },
  hintOptions: {
    schema: myGraphQLSchema,
    transformQueryText: queryText => doSomethingWithQueryText(queryText)
  }
});

Example of this in action:

In here I make use of fragments that are not in document, but are supplied by Gatsby, and both lint (no “unknown fragment” error) and hint (autocompletion for fragments supplied by Gatsby) works as expected for Gatsby usecase:

Above screenshot is result of some monkey patching (just to to make proof of concept that this can work).

I would be happy to submit pull request, but wanted to check first if this is something that would be welcome here.

[imolorhe]

@acao Looking at this, I think the external fragments solution should be sufficient for this? Are there potentially any other use cases where this ability to transform the query before sending to LSP (which specifically means affecting the linting and hinting only) makes sense?

[acao]

though… for just the purpose of manipulating operations… I’m remembering that this is a goal of @onegraph folks for explorer, and it provides us a cleaner way of implementing externalFragments without changing the external API.

when it makes sense to manipulate graphql documents - when executing operations - which happens using graphiql or playground or vscode-graphql extension client, you don’t have as much control over being able to manipulate documents appending externalFragments is nice, but a method for manipulating the query AST before execution and optionally providing language features is neat.

other thoughts:

• custom graphiql content pane plugins could, amongst other things, provide custom operation editor hooks for manipulating AST (in the background even) in a custom operation (monaco or text-editor free) component.
• codegen config could potentially drive some of this, where there is customisation of operation documents (i.e., patterns such as appending an id parameter to each object).
• vscode-graphql has a provider for custom text editors that could be used to implement something like onegraph explorer.