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

fix: allow variables inference in GraphQLRequest #1081

Merged
merged 2 commits into from
Jan 30, 2022
Merged

Conversation

obmarg
Copy link
Contributor

@obmarg obmarg commented Jan 28, 2022

I noticed that the return type of a graphql.query<T, N>... call is
GraphQLHandler<GraphQLRequest<any>> - it's not propagating the
variables generic parameter into the return type. I assume this wasn't
intentional.

This change annotates the constructor of the GraphQLHandler class with
the correct generic parameters, so the return type should now be
GraphQLHandler<GraphqlRequest<N>>.

@codesandbox-ci
Copy link

codesandbox-ci bot commented Jan 28, 2022

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit b7a9e82:

Sandbox Source
MSW React Configuration

@kettanaito
Copy link
Member

Hey, @obmarg. Thank you for submitting this fix, it looks great!

Please, could you share a quick example of when this fails during usage? I'd like to put that example into a typing test in the repo so we can catch regressions on this.

@obmarg
Copy link
Contributor Author

obmarg commented Jan 29, 2022

@kettanaito - unfortunately I didn't see it fail - the older any type was too permissive, and was missing problems rather than causing them.

For context I was trying to write a typed version of the waitForRequest example in the docs. Here's an example that should have failed, but didn't seem to:

export const waitForRequest = <T extends GraphQLVariables>(
  server: SetupServerApi,
  handler: GraphQLHandler<GraphQLRequest<T>>,
): Promise<MockedRequest<GraphQLRequest<T>>> => {
  let requestId = '';
  return new Promise((resolve, reject) => {
    server.events.on('request:start', req => {
      if (req.body && typeof req.body === 'object') {
        const matchesMethod =
          handler.info.operationName === req.body.operationName;
        if (matchesMethod) {
          requestId = req.id;
        }
      }
    });
    server.events.on('request:match', req => {
      if (req.id === requestId) {
        resolve(req as MockedRequest<GraphQLRequest<T>>);
      }
    });
  });
};

const myHandler = graphql.query<
  { id: string },
  { someVariable: string }
>('MyQuery', (req, res, ctx) => {
  return res(ctx.data({ id: '123' }));
});

const {
  body: {
    // THIS SHOULD FAIL, but doesn't because `variables: any`
    variables: { whatever },
  },
} = await waitForRequest(mockServer, myHandler);

It's not exactly a failure of your core use case though, so I'm not sure exactly how to extract a test from it.

obmarg and others added 2 commits January 30, 2022 12:05
I noticed that the return type of a `graphql.query<T, N>...` call is
`GraphQLHandler<GraphQLRequest<any>>` - it's not propagating the
variables generic parameter into the return type.  I assume this wasn't
intentional.

This change annotates the constructor of the `GraphQLHandler` class with
the correct generic parameters, so the return type should now be
`GraphQLHandler<GraphqlRequest<N>>`.
@kettanaito
Copy link
Member

@obmarg, fantastic! I've minimized your usage example and put it into an automated typings test so we can catch regressions on this across releases.

@kettanaito kettanaito changed the title fix: correct the return types of graphql handlers fix: allow variables inference in GraphQLRequest Jan 30, 2022
@kettanaito
Copy link
Member

Thank you for shipping this improvement, @obmarg! Welcome to contributors! 🎉

@kettanaito kettanaito merged commit 6e7ec28 into mswjs:main Jan 30, 2022
@github-actions
Copy link

🎉 This PR is included in version 0.36.8 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

2 participants