-
-
Notifications
You must be signed in to change notification settings - Fork 796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
transformSchema Map Enum Fields #1634
Comments
Very possible, but requires a new transform that maps values in schema and translates in request and result... PRs welcome |
It is potentially tricky to modify enum values as when transforming results you do not have actual access to field type, because of aliasing When transforming the request, the request can be visited with a schema using upstream graphql-js visit function, but there is no visitResult, because the power of GraphQL is that it lets you change the result shape. It would be interesting if you could ask GraphQL to give you an annotated result with the types but that is currently not spec, That would also help deal with overlapping fragments I think, but currently those are not allowed for the same reason, from what I recall. Anyway, we now support a individual transform context object that can be used to save which paths are modified when transforming the request and can be read by the transform result function. another approach is to encode the field types within the field names when transforming the request, That is basically how WrapFields/HoistField works |
Would be nice to just generally have a function that takes a document and result and visits the data and errors with the type info. |
motivation: #1634 (comment) todo: = add the parts where fields gets modified = each Object and Leaf type should let you modify data and errors = undefined should lead to no change, null to deletion
motivation: #1634 (comment) todo: = add the parts where fields gets modified = each Object and Leaf type should let you modify data and errors = undefined should lead to no change, null to deletion
motivation: #1634 (comment) portions of the result can be modified by specifying leaf type visitors that modify each value within the result based on its type, as well as object type visitors that can process each field within each object type. for example: leaf type visitors can be used to convert all dollars to euros, etc. object type visitors can be used to hoist or wrap object fields = how to handle errors? errors contain paths which may require modification (to enable field hoisting/wrapping) based on each of the fields along the path. so, we should call an errorVisitor with a pathIndex argument indicating the index within the path that represents the field for this errorVisitor, and call possibly multiple errorVisitors for each error if defined, for each field within the path, taking into account fields that are lists or lists of lists. only object type error visitors seem to be required -- might leaf type errors also be useful?
motivation: #1634 (comment) portions of the result can be modified by specifying leaf type visitors that modify each value within the result based on its type, as well as object type visitors that can process each field within each object type. for example: leaf type visitors can be used to convert all dollars to euros, etc. object type visitors can be used to hoist or wrap object fields = how to handle errors? errors contain paths which may require modification (to enable field hoisting/wrapping) based on each of the fields along the path. so, we should call an errorVisitor with a pathIndex argument indicating the index within the path that represents the field for this errorVisitor, and call possibly multiple errorVisitors for each error if defined, for each field within the path, taking into account fields that are lists or lists of lists. only object type error visitors seem to be required -- might leaf type errors also be useful?
motivation: #1634 (comment) portions of the result can be modified by specifying leaf type visitors that modify each value within the result based on its type, as well as object type visitors that can process each field within each object type. for example: leaf type visitors can be used to convert all dollars to euros, etc. object type visitors can be used to hoist or wrap object fields errors can be modified by specifying a function to modify each error as well as an errorVisitorMap that can specify a set of functions to run based on the fields within each individual error's path.
This should be easily addressable with visitResult One gotcha with type merging might be if enum type ast not recomputed from internal value asts, see 1dd9ae8 for similar fixes for fields |
Released in 6.0.14. Needs docs. |
Is it currently possible to use transformSchema to map enum field names?
I was hoping that RenameObjectFields was generic to allow this, but I doesn't seem to be.
Alternatively, I looked at implementing the Transform myself, but am now wondering if there is a simpler way to map enum field names.
My use case is I'm trying to translate enums in a kind of i18n way.
The text was updated successfully, but these errors were encountered: