monaco-graphql tabs through intellisense too aggressively

[jeffsee55]

When you enter tab so select an intellisense option, it immediately drops you into the nested properties. This is different from codemirror graphql where it just puts you at the end of the word. This is mainly an issue when you have arugments you'd like to provide (especially when they're required)

https://www.loom.com/share/e20881c74d2f49f4858d508539c79a7a

[acao]

first feedback about this new feature 🎂 ! recently introduced this to graphql-language-service-server and vscode-graphql as well

this is very helpful feedback! I hear this and could see how this would get annoying.

it's just so temptingly easy to add this on completion because of command and insertText in monaco.languages.CompletionItem. but also this seems like bad DX in retrospect, and makes field arguments more difficult to use

a few easier options for now:

1. make this an opt-in feature
2. only expand selection set for leaf fields without any arguments?
3. only expand selection set for leaf fields with required arguments? (more expensive, is that even useful if you want to provide arguments though?)

more difficult, may take longer:

4. if the field type has required arguments, expand the selection set automatically below as an additionalInsertText, but move the cursor to complete for the first argument. like this:

query {
  chosenField(|) {
    #selection set expanded, but cursor is in arguments
  }
}

5. choose to use an editor command/keybinding for this sort of behaviour similarly to graphiql? (I think this may be the best option to avoid unexpected behavior for now). another or perhaps complementary option along this route would be a code action lightbulb that expands a selection set if you've left one un-expanded

definitely will take longer:

6. i have a WIP from this effort for required field and argument completion as well, but there are still some open DX questions and issues

also while we're here, can I ask - would it be helpful for it to be clearer in suggestions when fields or arguments are required? I've also thought of modifying the suggestion sort to boost required fields or arguments to the top of the suggestion list.

[jeffsee55]

These are really interesting options! It's really hard to say because this is such a feel thing. I'd rather step through a bit more slowly because so much of GraphQL is about discovery 🤔 . In general, 5 sounds like the best option to me.

would it be helpful for it to be clearer in suggestions when fields or arguments are required?

How would it be more clear? I see the String! in the hint box but maybe there's more to it?

[acao]

oh great! I did get the type printing fully there. couldn't recall offhand

[acao]

finally about to release a fix for this. I'm sure you and I aren't the only ones annoyed by the outcome of this shoegun insertText experiment, haha

#2488

it will become an opt-in experimental feature, and your feedback and others will help us make this a much more well-rounded experience in the future, when it's ready. a custom keyboard shortcut for this with support for required arguments is a must have!