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

Empty variables, consider using never type? #147

Open
christoomey opened this issue Oct 1, 2020 · 2 comments
Open

Empty variables, consider using never type? #147

christoomey opened this issue Oct 1, 2020 · 2 comments

Comments

@christoomey
Copy link

First, thank you so much for this wonderful project! It's extremely impressive and I've been very happy with it overall.

I did run into one small issue for a query with no variables, e.g.

const QUERY = gql`
  query Users {
    users {
      id
      name
    }
  }
`

For this query, the generated type of the UsersVariables would be:

export type UsersVariables = {};

Unfortunately, TypeScript is a bit overly permissive with the {} literal value and will allow any object to be assigned:

type UsersVariables = {}

// The following is incorrect as the query takes no variables,
// but the typing allows it
const variables: UsersVariables = { name: 'hello' }

// Using a more restrictive type, we can prevent this:
type UsersVariablesNever = { [index: string]: never };
// This line will now properly highlight the `name` value
// as an error since the query doesn't accept any variables
const neverVariables: UsersVariablesNever = { name: 'hello' }

TypeScript playground with this example


My suggestion would be to use the more restrictive { [index: string]: never } instead of {} for empty variable type definitions.

@Quramy
Copy link
Owner

Quramy commented Oct 1, 2020

@christoomey

Thanks your feedback.

For this query, the generated type of the UsersVariables would be:

export type UsersVariables = {};

I think it' better to not generate variable type for no-variadic query. How about it ?

@christoomey
Copy link
Author

That is certainly an option and would fix the correctness issue. In my case I was hoping to rely on the graphql query as the source of truth and then be able to use the generated types to constrain my system. My hope was to be able to always wire up the variables and have them correctly give me feedback.

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

2 participants