You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When generating the docs for a graphql-ruby schema, the resulting documentation includes types used for introspection such as __Type, __Field, __Directive etc. which I'd rather not have in my API documentation.
Also, I might want to hide some mutations, fields or types in the docs because I use them for internal purposes and I don't want other clients to rely on them (I know that ideally I should hide them in the schema itself, but it's not always convenient or desirable).
Describe the solution you'd like
I envision an option similar to the notices one: a user-provided proc that, given the schema member path, returns true if the member should be hidden.
To satisfy the use-case described above, one could write the option as: (feel free to choose a different/better name for the option)
@Fs00 Makes sense to me, thanks for logging this! Seems like a worthwhile improvement. Not sure if I'll be able to dig into it soon, but it's certainly open for others to take on if they want. 👍
Is your feature request related to a problem? Please describe.
When generating the docs for a graphql-ruby schema, the resulting documentation includes types used for introspection such as
__Type
,__Field
,__Directive
etc. which I'd rather not have in my API documentation.Also, I might want to hide some mutations, fields or types in the docs because I use them for internal purposes and I don't want other clients to rely on them (I know that ideally I should hide them in the schema itself, but it's not always convenient or desirable).
Describe the solution you'd like
I envision an option similar to the
notices
one: a user-provided proc that, given the schema member path, returns true if the member should be hidden.To satisfy the use-case described above, one could write the option as: (feel free to choose a different/better name for the option)
The text was updated successfully, but these errors were encountered: