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

[pieh]

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.

[jide]

Hey !

Is this feature considered ?

[acao]

yes, though it might be a bit before it lands in the GraphQL IDE ecosystem.
there is potentially another way to acccomplish this further down the stack in the language service interface. ill link to the relevant discussion once we finish migrating them over from the graphql-language-service repository

[jide]

Ok, thanks for the input ! I'd be very interested in any way (even hacky !) to provide fragments somehow.

[acao]

@Neitsch I feel like there was an issue or PR for GLS that addressed this via GraphQL Config but I couldn't find it - either way, do you feel like this is something that could be (better) addressed further down the stack in GLS, in the interface or service perhaps? It seems there is a wide demand for tooling that allows users to supply custom directives. I would like to implement something that works across the IDE stack, rather than just in a web IDE implementation

[acao]

#612 here it is - I haven't looked closely enough to be sure, but it seems like these are working towards the same goal, just with very different paths to implementation?

[acao]

I think I understand better the need for this, and potentially in monaco-graphql as well. @imolorhe and @yoshiakis what do you think? is there a more codemirror-centric way to do this? this would mean being able to transform the query text before executing operations, not transforming the text in the editor. the fragments approach only achieves this with fragments. it would be nice to provide the DocumentNode AST here as well

[acao]

this would have been a far more powerful API to expose than what I introduced with externalFragments - oops!

[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]

i agree. it seems powerful to manipulate the AST before requesting language features from these service levels, but I don't see that as the purpose of the LSP, beyond what externalFragments already provides. When it comeås to SDL especially, full language support is great, but it would not be the responsibility of a language server to manipulate schema documents, except for, say, suggesting CodeActions and such eventually.

[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.