Support TypedDocumentNode about graphql-hooks

[simoneb]

Just curious, why was this closed?

It was closed by automation.

[luke88jones]

@machineghost I don't believe adding support for TypedDocumentNode makes sense for this library. This feature is intended to allow a response type to be inferred from the DocumentNode object passed to the request, however, graphql-hooks works with GQL queries as strings. All of the current library methods support generic types so it is possible to provide type information for your requests e.g.

import { useQuery } from 'graphql-hooks'

type MyResponse = {
  id: string
  name: string
}

const HOMEPAGE_QUERY = `query HomePage($limit: Int) {
  users(limit: $limit) {
    id
    name
  }
}`

function MyComponent() {
  const { loading, error, data } = useQuery<MyResponse>(HOMEPAGE_QUERY, {
    variables: {
      limit: 10
    }
  })

  if (loading) return 'Loading...'
  if (error) return 'Something Bad Happened'

  return (
    <ul>
      {data.users.map(({ id, name }) => (
        <li key={id}>{name}</li>
      ))}
    </ul>
  )
}

I'll update the existing library documentation to make the typescript integration clearer.

[machineghost]

Just curious, why was this closed? Is it a lot of work to implement, or does graphql-hooks just not care about supporting TypeScript?

[sepbot]

@luke88jones typed document node is supposed to be used alongside of the code generator, which will generate overloaded functions that will map queries declared as string literal to document node. so you pass your query declared in a string literal to a graphql function that returns a DocumentNode with the correct types defined, allowing inference of the return type from the query string.

your example requires declaring the return type yourself and removing the compile time checks that you could be getting otherwise.

[luke88jones]

Hey @sepbot the problem is that graphql-hooks receives the GQL query as a string so we're unable to support the type. Below is the example of adding support linked above. This has an overloaded function signature where the operation variable extends DocumentNode. As we don't support receiving Document Nodes as input we can't support this feature.

import { TypedDocumentNode } from "@graphql-typed-document-node/core";

type GqlFetchResult<TData = any> = {
  data?: TData;
  errors?: Error[];
};

export function gqlFetch<TData = any, TVariables = Record<string, any>>(
  operation: TypedDocumentNode<TData, TVariables>,
  variables?: TVariables
): GqlFetchResult<TData>;
export function gqlFetch<TData = any, TVariables = Record<string, any>>(
  operation: DocumentNode,
  variables?: TVariables
): GqlFetchResult<TData> {
  // ...
}

[simoneb]

Upon further consideration, we could have a look at what it'd take to support DocumentNode queries. I'm not entirely sure how to go about it as we always only supported queries, mutations and subscriptions in the form of strings, but this might be a good start: https://github.com/apollographql/graphql-tag.

Ideally we should not depend on anything from the Apollo library though, so I'd see how other implementations how graphql clients generally do it.