Introduce result visiting #1718
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest changes of this PR are available as alpha in npm: Quickly update your package.json by running: |
yaacovCR
force-pushed
the
visit-result
branch
6 times, most recently
from
d918dda
to
4f1ea0f
Compare
yaacovCR
force-pushed
the
visit-result
branch
2 times, most recently
from
e02fa9f
to
803f032
Compare
This changes introduces a few generic functions for revisiting data = visitData can be used to recursively visit an ExecutionResult (or any object) it takes two functions, one executed when entering the object, one when leaving = visitResult can be used to visit a result by with a resultVisitorMap and/or an errorVisitorMap visitResult visits the result using the request, so it knows the object type for every object within the map, as long as the result includes __typename info when requesting abstract types, and also knows the field name for each aliased key within the object. * it executes the correct visitor from each objectVisitorMap included within the resultVisitorMap depending on the object type and field name * it executes object visitors on the object itself when entering and leaving the object using the values from the __enter and __leave dummy field names within the objectVisitorMap * it executes any visitors for leaf types included within the resultVisitorMap to provide a simple mechanism of visiting all fields of a certain leaf type errors can also be visited -- these are meant to provide opportunities for transforming a GraphQLError, including the path, and so, if an errorVisitorMap is included, error visitors from the map will be collected for each field found in the path of the original error.
Adds result wrapping capability to the following generic transformers = TransformCompositeFields = TransformInterfaceFields = TransformObjectFields = TransformRootFields = ExtendSchema = MapFields Adds result visiting usage to the following transfromers = WrapFields = WrapType = HoistField Result visiting was introduced within RenameTypes within the initial commit.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When transforming a delegating schema (i.e. utilizing the transformSchema method within transforms passed to wrapSchema), one technique for result transformation is to defer the work until field resolution time, i.e. by wrapping the resolve method for the appropriate field within the delegating schema.
This approach saves a round of result tree traversal., but, unfortunately, causes several issues:
= return type inconsistencies that affect using these fields for stitching (see: #1725, yaacovCR#35)
= type merging issues when fields are wrapped only in some subschemas
WrapType, WrapFields, HoistField, ExtendSchema transformers have been converted to utilize their transformResult methods to visit the result.
This PR embraces that result visiting as an independent step when required and introduces some generic utility functions to make that easier.
To do, in separate future PRs:
= use result visiting to implement leaf value conversion #1634
= use result visiting to convert errors from subschemas to full paths, a la #1650 to solve #1047. This set of changes is now a breaking change because getErrors is exported, and likely should be deferred until the next major release, which probably (?) should coincide with the next major release of upstream graphql-js.