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

[Feature Request]: automatic type resolvers from graphql tags #4388

Open
EloB opened this issue Jul 24, 2023 · 0 comments
Open

[Feature Request]: automatic type resolvers from graphql tags #4388

EloB opened this issue Jul 24, 2023 · 0 comments

Comments

@EloB
Copy link

EloB commented Jul 24, 2023

AFAIK Typescript doesn't have the possibilities to infer the TemplateStringsArray that prevents automatic type resolving.

It seems like an hard issue for TypeScript to solve. The request has been around since 2019:
microsoft/TypeScript#33304

I was thinking if we could create an alternative to:

type CurrentGraphQLFn = (texts: TemplateStringsArray): GraphQLTaggedNode;

graphql`
  query something {
    // ....
  }
`

To something like this:

type GraphQLQuery<T extends string> = T extends keyof RelayPersistentQueries
  ? RelayPersistentQueries[T]
  : GraphQLTaggedNode;

type FeatureRequestGraphQLFn = <T extends string>(query: T): GraphQLQuery<T>;

// $graphql would be a new function from relay and keep the other one untouched for backward compatibility.
const query = $graphql(`
  query something {
    // ...
  }
`)

If the compiler creates a type definition file with all queries like Record<string, OperationType> as the RelayPersistentQueries we would be able to automatically type queries.

This is good either way because if they manage to add the inferring feature to Typescript than we already have this functionality and would be easy to add to our graphql function as well. Then we only deprecate that $graphql function because I can agree that template literals looks better.

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

No branches or pull requests

1 participant