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

[graphiql] Support the proposed "incremental: ..." response format #3470

Closed
rmosolgo opened this issue Dec 4, 2023 · 3 comments
Closed

[graphiql] Support the proposed "incremental: ..." response format #3470

rmosolgo opened this issue Dec 4, 2023 · 3 comments

Comments

@rmosolgo
Copy link
Contributor

rmosolgo commented Dec 4, 2023

Hi! I'm trying to use GraphiQL with @defer. I found that it has some support built in via enableIncrementalDelivery, which defaults to true.

However, there's a long-running proposal to change the standard response structure: graphql/graphql-spec#742 .In that proposal, each patch would include a { incremental: [ ... ] } array which includes { data: ... , path: ... } entries.

Although it's only a proposal, it was implemented in GraphQL-JS about a year ago (graphql/graphql-js#3659) and has also been added to urql and apollo client

It looks like GraphiQL expects data and path to be top-level keys in the server's response:

// We pull out errors here, so we dont include it later
const { path, data, errors, ...rest } = part;

What do you think about also checking for incremental: ... entries there, to support this new response format?

Thanks!

@acao
Copy link
Member

acao commented Dec 5, 2023

our implementation should be updated with whatever the language spec you linked to, and in addition, whatever the graphql over http spec supports! please feel free to open a PR if you like!

@injae-kim
Copy link

Maybe resolved by #3580?

@rmosolgo
Copy link
Contributor Author

Looks like it to me -- thanks for sharing that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants