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

refactor: streamline buildExecutionContext #3196

Closed
wants to merge 14 commits into from

Conversation

yaacovCR
Copy link
Contributor

@yaacovCR yaacovCR commented Jun 22, 2021

  1. pass named arguments to buildExecutionContext so that ExecutionArgs or SubscriptionArgs can be simply passed through
  2. move assertValidExecutionArguments into buildExecutionContext, as only used there.
  3. streamline returnType by throwing a GraphQLAggregateError with any processing errors rthar than returning either ExecutionContext or an array of GraphQLErrors.

Motivation: these changes significantly slim down execute/subscribe, paving the way for refactoring the execution methods into a class where the constructor uses to buildExecutionContext to set up the executionContext (or its constituent properties) as class member(s).

Depends on #3195

@yaacovCR yaacovCR changed the title refactor: throw GraphQLAggregateErrors from buildExecutionContext refactor: streamline buildExecutionContext Jun 22, 2021
@yaacovCR yaacovCR force-pushed the consolidate-subscription branch 3 times, most recently from ec4518e to dc88bcf Compare October 4, 2021 14:02
All operations, including subscription operations, are covered by the execution section of the GraphQL spec
...and executeQueryOrMutationRootFields

to prepare for integration of executeSubscription
this function currently does not throw GraphQLErrors -- it is not within the parallel try block within execute
to executeSubscriptionRootField
to operate only on ExecutionContext
-- In at least a few cases, destructuring assignment from exeContext can improve code readability.
-- Overrides to exeContext can be set using object spread syntax.
@yaacovCR yaacovCR force-pushed the throw-on-build-error branch 5 times, most recently from 9b99e35 to 9cab1b5 Compare October 6, 2021 21:38
@yaacovCR
Copy link
Contributor Author

yaacovCR commented Oct 6, 2021

@IvanGoncharov , this is ready for review. based on the feedback to #3192, I have abandoned the throw on build error approach (despite the retained name of the branch) and am now basically going at least initially with @glasser suggestion #3169 (comment) to separate out the document normalization and variable coercion steps from the main execute flow.

Execution arguments object can be passes as-is to the function.
assertValidExecutionArguments can be called within the function rather
than prior
...capable of processing requests of all operation types.

ExecutionArgs now augmented with all relevant arguments for
subscriptions as well.
existing flow hid the execution request spec portion within the
execution context object setup -- the algorithm steps belong within the
function itself.
@yaacovCR
Copy link
Contributor Author

yaacovCR commented Oct 7, 2021

Closed this in favor of PR stack 3293 => 3302.

@yaacovCR yaacovCR closed this Oct 7, 2021
@yaacovCR yaacovCR deleted the throw-on-build-error branch October 7, 2021 21:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant