Skip to content
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

Closed
teebszet opened this issue Jun 11, 2020 · 5 comments
Closed

transformSchema Map Enum Fields #1634

teebszet opened this issue Jun 11, 2020 · 5 comments
Labels
docs Focuses on documentation changes

Comments

@teebszet
Copy link

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.

@yaacovCR
Copy link
Collaborator

Very possible, but requires a new transform that maps values in schema and translates in request and result...

PRs welcome

yaacovCR referenced this issue in ardatan/graphql-mesh Jun 11, 2020
@yaacovCR
Copy link
Collaborator

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

@yaacovCR
Copy link
Collaborator

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.

@ardatan ardatan added the feature New addition or enhancement to existing solutions label Jun 11, 2020
yaacovCR added a commit that referenced this issue Jun 15, 2020
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
yaacovCR added a commit that referenced this issue Jun 21, 2020
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
yaacovCR added a commit that referenced this issue Jun 22, 2020
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?
yaacovCR added a commit that referenced this issue Jun 23, 2020
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?
yaacovCR added a commit that referenced this issue Jun 26, 2020
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.
@yaacovCR
Copy link
Collaborator

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

@yaacovCR yaacovCR added the waiting-for-release Fixed/resolved, and waiting for the next stable release label Jul 16, 2020
@yaacovCR
Copy link
Collaborator

Released in 6.0.14. Needs docs.

@yaacovCR yaacovCR added docs Focuses on documentation changes and removed feature New addition or enhancement to existing solutions waiting-for-release Fixed/resolved, and waiting for the next stable release labels Jul 17, 2020
@ardatan ardatan closed this as completed Mar 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Focuses on documentation changes
Projects
None yet
Development

No branches or pull requests

3 participants