Skip to content

Conversation

@eddeee888
Copy link
Collaborator

Description

Related: #1017

client.request can an object as the first param with 4 key-value pairs:

  • document: the GraphQL doc
  • variables: the GraphQL operation variables
  • requestHeaders: the request headers for the request
  • signal: AbortSignal to set request's signal

Previously, the document, variables and requestHeaders were passed in as positional params, which didn't allow for signal to be passed in. This PR changes that:

  • by accepting signal as the last param for each SDK function
  • converts the SDK functions to use the object param style, instead of positional param style

Type of change

  • New feature (non-breaking change which adds functionality)

Note: this could be a breaking change in tests if consumers try to spy on the client.request function and try to assert said function to be called with certain params.
However, there's no functional changes in terms of the public interface i.e. if users just test using the SDK functions, it'd still work, so I think this is a minor instead of a breaking change.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can
reproduce. Please also list any relevant details for your test configuration

  • Unit test

@changeset-bot
Copy link

changeset-bot bot commented May 26, 2025

🦋 Changeset detected

Latest commit: a1a80fc

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@graphql-codegen/typescript-graphql-request Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@github-actions
Copy link
Contributor

🚀 Snapshot Release (alpha)

The latest changes of this PR are available as alpha on npm (based on the declared changesets):

Package Version Info
@graphql-codegen/typescript-graphql-request 6.3.0-alpha-20250526125727-a1a80fc3dfa5bc89746ab0314c7a44b16fffc45a npm ↗︎ unpkg ↗︎

Comment on lines 146 to 151
o.operationVariablesTypes
}, requestHeaders?: GraphQLClientRequestHeaders): Promise<${o.operationResultType}> {
}, requestHeaders?: GraphQLClientRequestHeaders, signal?: RequestInit['signal']): Promise<${o.operationResultType}> {
return withWrapper((wrappedRequestHeaders) => client.request<${
o.operationResultType
}>(${docVarName}, variables, {...requestHeaders, ...wrappedRequestHeaders}), '${operationName}', '${operationType}', variables);
}>({ document: ${docVarName}, variables, requestHeaders: { ...requestHeaders, ...wrappedRequestHeaders }, signal }), '${operationName}', '${operationType}', variables);
}`;
Copy link
Collaborator Author

@eddeee888 eddeee888 May 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you familiar with how the generated SDK work, and could help me do a sense check please @jasonkuhrt?

Given a doc like this:

const AddDocument = gql`
    query Add($x: Int!, $y: Int!) {
  add(x: $x, y: $y)
}
    `;

Currently, it's generating a function that takes in variables and requestHeaders as positional params, then uses client.request's positional param like this:

client.request<AddQuery>(
  AddDocument, 
  variables, 
  {...requestHeaders, ...wrappedRequestHeaders }
);

This PR changes it to use single object param like this:

client.request<AddQuery>({ 
  document: AddDocument, 
  variables, 
  requestHeaders: { ...requestHeaders, ...wrappedRequestHeaders }, 
  signal 
})

2 questions from me:

  • For graphql-request@7, I can see that there are only 4 possible keuys for the object style, is this correct?
  • Do you see any issues with this approach? I'm mindful of v8 development so I don't want to change how v7 SDK work too much to avoid breaking changes.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, not familiar with this generator myself. IIUC your object there with 4 keys is I guess correct. I would trust whatever the TS types say. Its weird to me that signal gets shoved in there but I suspect it was added just to unblock people and keep things moving at some point.

In terms of issues with approach, hard for me to say having been distant from v7 for a while and not familiar with this generator so can't help much off hand with that. But if you make a quick test and it seems to be working, then that's a decent confirmation that it should be working in other cases too.

Sorry to not be more helpful!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jasonkuhrt ! All good! Appreciate the context and advices.
I've done a few tests and it's working fine, will merge this 🙏

@eddeee888 eddeee888 requested a review from dotansimha May 28, 2025 12:15
@eddeee888 eddeee888 merged commit 32a5a00 into main May 28, 2025
13 checks passed
@rodsouto
Copy link

rodsouto commented Jun 2, 2025

FYI in my case, this was a breaking change, as the signal interface is not compatible with the interface of @types/node

so if someone else gets the error Type 'AbortSignal' is not assignable to type 'AbortSignal'. Two different types with this name exist, but they are unrelated. Types of property 'onabort' are incompatible the fix is to downgrade @graphql-codegen/typescript-graphql-request to 6.2.0

@msandula12
Copy link

FYI in my case, this was a breaking change, as the signal interface is not compatible with the interface of @types/node

so if someone else gets the error Type 'AbortSignal' is not assignable to type 'AbortSignal'. Two different types with this name exist, but they are unrelated. Types of property 'onabort' are incompatible the fix is to downgrade @graphql-codegen/typescript-graphql-request to 6.2.0

Also ran into this and was therefore unable to update to 6.3.0. On @types/node version 24.3.0, for reference.

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.

5 participants