-
Notifications
You must be signed in to change notification settings - Fork 2k
refactor: consolidate subscription into execution #3195
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
Conversation
e4f2ace
to
d8e3254
Compare
dc88bcf
to
112feed
Compare
112feed
to
83a7f41
Compare
@IvanGoncharov I have lifted the dependency for this PR on the #3192 This is now just code reorganization/polish, and I believe can be released in v16. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please make a separate PR where you just merge the subscription
folder to execute
.
That way we don't lose history on subscribe.ts
and also it would be way easier to see changes in that file.
One issue though is that people using |
expect(await createSourceEventStream(schema, document)).to.deep.equal( | ||
result, | ||
); | ||
const exeContext = buildExecutionContext( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
buildExecutionContext
is not a part of public API so shouldn't use it in our tests
createSourceEventStream
is part of public API so it should be usable as previously with schema + document
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
I have added some more commits where I removed the subscribe.ts file entirely (it's superfluous now that subscribe is part of execution. So I am not sure how we are going to avoid losing the hx from that file. Thoughts? |
see #3292 I will work soon on rebasing this PR and addressing the other code review, but I suppose we can pick up at least from there. |
...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 execution file
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.
Execution arguments object can be passes as-is to the function. assertValidExecutionArguments can be called within the function rather than prior
@yaacovCR It totally ok to lose history. I just prefer to have as small as possible bridge PR for that, we should separate commit where we move content and also keep content intact as much as possible. |
...capable of processing requests of all operation types. ExecutionArgs now augmented with all relevant arguments for subscriptions as well.
535e210
to
758d31e
Compare
ok the separate PR for code move is done, and this PR is rebased, but I still need to address your other feedback |
actually i think the rebase was a bit unsuccessful, will go back through it commit by commit later. maybe i will find something else to break out into a different PR as well |
@yaacovCR sounds good 👍 |
Closed this in favor of PR stack 3293 => 3302. |
subscription
operations are described by the 'Execution' section of the spec.