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
Many of the schema transforms currently implemented and provided by graphql-tools use the visitSchema function under the hood to walk through the schema AST and transform it.
If you're creating a schema transform class that uses a transformSchema method, there's not much transforming you can do without a function like visitSchema. Given that, it makes sense to provide visitSchema as a supported feature for developers writing custom transforms.
I think it would be great if these functions were documented and exported as part of the main package. Without having them documented and exported at the top-level, the custom schema transform feature feels incomplete.
Workaround
Currently, in order to make use of visitSchema (and related functions), it must be imported from nested directories in the package:
Would love to see this feature be implemented as more use cases for transformSchema are found for our team. I'd go so far as to suggest building out tools like this even further.
We could create visitors for more fine-grained use cases while transforming schemas, like having visitors for specific types: visitInterfaces, visitUnions, visitEnums, etc. It reminds me a bit of the visitor methods of SchemaDirectiveVisitor. So I could possibly see these being methods we could utilize when building our own transform rules:
Use Case
Many of the schema transforms currently implemented and provided by
graphql-tools
use thevisitSchema
function under the hood to walk through the schema AST and transform it.If you're creating a schema transform class that uses a
transformSchema
method, there's not much transforming you can do without a function likevisitSchema
. Given that, it makes sense to providevisitSchema
as a supported feature for developers writing custom transforms.I think it would be great if these functions were documented and exported as part of the main package. Without having them documented and exported at the top-level, the custom schema transform feature feels incomplete.
Workaround
Currently, in order to make use of
visitSchema
(and related functions), it must be imported from nested directories in the package:The text was updated successfully, but these errors were encountered: