monaco-graphql: handle SDL & high throughput schema changes

[cshaver]

(carrying over this discussion with @acao from discord)

We've been using monaco-graphql to edit graphql schemas across multiple files, and it seems like the autocomplete (at least at the document level) is actually pretty operation-specific (e.g. suggesting query/mutation/subscription/fragment, as opposed to type/interface/enum/etc):

🖼 Screenshot of autocomplete suggestions

One thing to note is that currently we're updating the mode schema on each change (debounced), but the SDL passed to the monaco-graphql API could be invalid — this causes some trouble as the graphql autocomplete suggestions come and go as the schema is or isn't valid. I know the worker should get destroyed and re-created on each schema change, but our setup (and our schema being very large) seems to cause some crashing issues where there are still a number of worker threads hanging around:

🖼 Screenshot of sources tab

Two major issues here:

• inline SDL autocompletion features are not working anymore!!
• High throughput changes to the graphql schema for monaco-graphql cause issues with workers

[acao]

oh my goodness, yes the worker should definately not be loading like that. it looks like the initializeMode() is being invoked many times, perhaps?

[cshaver]

Notes from pairing with @acao today! 🎉

we looked at:

• confirmed on the latest vite example, too many workers is triggered by schema changes
• look at how schema is shared with the worker, since this can change often
  • e.g. innoDB, cache api

found some bugs:

• (monaco-editor) bg missing on autocomplete box - need to create a bug ticket for them!
• repro'd https://github.com/graphql/graphiql/pull/2171/files
• monaco-react webpack example has some bugs that vite doesn't
  • would be cool to get a basic cypress test (get model markers from monaco), visual diff testing
• (monaco?) lots of logs from monarchCommon on parsing directives
• improve webpack example config, so the web workers output name aren't hashed
• devx of running examples from root maybe: yarn run example:<example name>

[acao]

Here's the video!

https://www.dropbox.com/home/Apps/Jitsi%20Meet/Recordings?preview=wholeaugustsoptfree+on+2022-02-22+20-13.mp4

[acao]

i am so confused, because autocompletion should work just for an inline SDL types in monaco graphql just last year. I remember this because I was able to use monaco-graphql to test improvements to autocomplete that had the same effect in vscode-graphql And other lsp clients

getAutocompleteSuggestions() accepts the schema and the input string, and our custom parser is supposed to extract SDL types from the string as well, and should inline complete for types in the same file, as long as there is already a source schema.

For example, I recall developing implements autocompletion for multiple interfaces/types using monaco-graphql, and the autocompletion worked with inline defined interfaces!

I have a branch in the works where I make schema optional for getAutocompleteSuggestions()

[acao]

To put it simply, we use the same autocompletion interface in the LSP server and monaco-graphql, so something like object type field type completion for inline types, or autocompletion for unions for inline types, or inline input types as argument types, or implements for inline defined types & interfaces should still be working, without having to merge the SDL file user input to the input GraphQLSchema primitive. We even have unit (for ls) & integration tests (for lsp, not monaco) that cover these cases!

If it’s not working naturally then something has gone awry!

[acao]

Question - does the file URI for the SDL file match up for json variables features by chance? Or perhaps something related to that new logic dangerously assumes operation editing which causes SDL completion to fail?