Grouping and folding of fields in large Schemas by directives

[t1]

In very large schemas, esp. in a federated supergraph, it becomes cumbersome to work with that many fields; not only, but probably most prominently, in Query itself.

It would be cool to be able to group and hide fields, to better focus on specific sub-sets, if they are annotated with directives. Say you have a @tag directive with the values planets, characters, etc. on most fields. If you enable grouping for tag, the list of fields in the schema view as well as in the auto completion is subdivided by the different actual tag values. By clicking on the group name, you can fold and hide all the values you're currently not interested in. This folding is sticky, i.e. if you fold it in the schema view, it remains folded also in the auto completion and vice versa. Until you unfold it again. If you fold multiple values, they merge into a single line. There is even an option to fold all but one value.

I'm unsure about a good UI for enabling the grouping for a directive, because directives can have none or multiple arguments, maybe even optional.

[acao]

I think this would be 100% doable if we make there be an official spec directive to use for grouping, such as @tag, another solution to this that has been offered is namespaces. the graphql-wg repo is where you could propose this, I think it's a great idea!

[t1]

I thought that this could be done with arbitrary directives... or at least those that have exactly one argument.

[acao]

this is also possible! but we have to tread carefully, because we are a reference implementation, and especially the schema doc explorer. people might assume whatever the default is is official spec, which is why i would want to check if there are any:

• existing adhoc specs already in use
• existing related spec proposals
• borrowing from similar specs like jsdoc/typedoc superset (your proposal works for this!)

Your choice for the default is already great, but If one doesn't exist, we can pair it with a spec proposal and add the behavior ourselves until it's accepted in the spec and part of graphql-js, like with type.deprecationReason. This way, we can adopt it while the spec is still a draft, and users can customize the name of the directive as needed