Support /* GraphQL */ comment tags

[jaydenseric]

Like mentioned in the docs, a lot of GraphQL clients (such as graphql-react) don't need a template string tag. Such untagged template literals can be marked with a leading /* GraphQL */ comment for syntax highlighter, linters, and other tools.

const query = /* GraphQL */ `
{
  viewer {
    id
  }
}
`

This is a superior solution to a fake tag, which inconveniently needs to be imported everywhere and causes unnecessary bundle size and performance overheads.

[jaydenseric]

In the meantime, fake-tag is a better solution than the copy-paste code suggested in the readme:

import gql from 'fake-tag'

const query = gql`
{
  viewer {
    id
  }
}
`

[jnwng]

i agree - short-term it’d make sense to update the readme until the comment feature is added.

On Wed, Apr 24, 2019 at 5:40 PM Jayden Seric [email protected] wrote:

In the meantime, fake-tag https://github.com/jaydenseric/fake-tag is a better solution than the copy-paste code suggested in the readme:

import gql from 'fake-tag'

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apollographql/eslint-plugin-graphql/issues/224#issuecomment-486477131, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIRCRUXW6CC4IY6WAXF5FTPSD4XZANCNFSM4HHBBGVQ .

[lukehedger]

Is this being worked on?

[a-marcel]

Any news about this feature ?

[rigelglen]

For anyone who does not want an additional dependency, you can just do

export const gql = String.raw;

And then just use gql as you normally would. Your editor and this plugin will recognize it with no issues.

const query = gql`
{
  viewer {
    id
  }
}`

[jaydenseric]

@rigelglen see the fake-tag “Why not String.raw?” readme section:

This may be temptingly simple:

const gql = String.raw
const QUERY = gql`
  {
    foo
  }
`

However, it doesn’t unescape characters. For the usage example, if you console.log(typeDefs) > before and after replacing the import with const gql = String.raw you will see the difference in > the type description markdown:

    "A foo."
    type Foo {
-     "The `Foo` ID."
+     "The \`Foo\` ID."
      id: ID!
    }

[taletski]

Would be really nice to have it since usage of template strings is not possible when using the graphql codegen.

@jaydenseric do you have plans to support gql functions like gql(document: string)?

I read through the docs but can't find a working solution except for patching the visitor.

[jaydenseric]

@taletski I'm not sure exactly what you mean. Which repo/package are you referring to?

[taletski]

@jaydenseric sorry for providing a little context.

I am using gql codegen client-preset to generate strict types for all gql operations in my project.

This tool goes over ts(x) files, finds gql documents and generates for them own gql() function that returns a TypedDocumentNode. The benefit is that it allows my GQL client functions to automatically infer an exact TS response/variables types that contains only the fields I query and only the variables I use for this particular operation.

Example:

#schema.graphql

type Queries {
  backendQuery(foo: String!): BackendQueryResponse
}

type BackendQueryResponse {
  foo: String
  bar: String
}

// queries.ts
import { gql } from 'my-codegen-setup/generated/gql.ts'

// note that I am querying only `foo`, but not `bar`
const MY_QUERY = gql(`
  query myQuery($foo: String!) {
    result: backendQuery(foo: $foo) {
      bar
    }
  }
`)

// Component.tsx

const { data } = useQuery(MY_QUERY, { variables: { foo:  'test'} });
//        ^                           ^^^^^^^^^
//        |                           |
//        |                            - Variables are now strictly typed, TS will not allow me to omit required ones
//         - Type of `data` is { result: { bar?: string } }

In the example above the caveat is that the generated gql() function can no longer be used as a template string tag, but should be applied as a regular function to produce TypedDocumentNode.

For now, eslint-plugin-graphql recognises only template literal tags and magic comments though.

So my questions is, do you plan to support the gql() function from the use case above?

[jaydenseric]

@taletski

So my questions is, do you plan to support the gql() function from the use case above?

Support it in what repo/package? If you mean eslint-plugin-graphql, I'm not an owner or maintainer of that. I'm just an external contributor via some PR's.

[taletski]

@jaydenseric sorry for confusion. I think I should proceed with a feature request and/or a PR on my own for that

[Urigo]

This library is no longer maintained Check out top of the README file which directs you to graphql-eslint