The recommended client-preset feels subjectively worse than previous solutions

[ChristianIvicevic]

Hey folks,

I am dropping by to share my opinion and ask whether I am missing something critical here. Previously I have been successfully using the typescript-react-query plugin to generate hooks based on my queries. However I noticed this on the plugin docs page

As the new preset is explicitly recommended I thought to give it a try and have been very disappointed. Previously I used to declare queries and had access to a useFooQuery hook that was strictly-typed, had a solid key, even based on variables and did not require any hardcoding of paths etc.

With the new preset I see that documents are typed based on queries and mutations in files, but the example in docs (https://the-guild.dev/graphql/codegen/docs/guides/react-vue#writing-graphql-queries) show that I have to manually declare my keys and pass a fetcher with a hardcoded URL etc.

  const { data } = useQuery(['films'], async () =>
    request('https://swapi-graphql.netlify.app/.netlify/functions/index', allFilmsWithVariablesQueryDocument, {
      first: 10 // variables are typed too!
    })
  )

While this could be extracted into a reusable function I find that to be strictly worse in terms of DX. Additionally the keys are not automatically generated either, so once again it requires custom logic to make it a bit safer and more ergonomic.

What I am curious is, why is this recommended now? What are advantages here that outweigh the reduced DX that I am facing here?

[n1ru4l]

Hey @ChristianIvicevic.

As you mentioned your concerns are primarily related to the dedicated react-query plugin.

I can understand that this change takes some of the convenience you had previously when generating dedicated hooks for each GraphQL operation.
On the other hand, it makes this library more straightforward to use for different client libraries without having to maintain an almost infinite variation of plugins, of which most of them only a small fraction of people use.

As you mentioned a solution could be to write your own small wrapper react hook:

import type { TypedDocumentNode } from "@graphql-typed-document-node/core";
import { useQuery } from "@tanstack/react-query";
import { Kind, ASTNode, OperationDefinitionNode } from "graphql";
import request from "graphql-request";

const isOperationDefinition = (def: ASTNode): def is OperationDefinitionNode =>
  def.kind === Kind.OPERATION_DEFINITION;

export function useGraphQL<TResult, TVariables>(
  document: TypedDocumentNode<TResult, TVariables>,
  ...[variables]: TVariables extends Record<string, never> ? [] : [TVariables]
) {
  return useQuery(
    [
     // This logic can be customized as desired
      document.definitions.find(isOperationDefinition)?.name,
      variables
    ] as const,
    async ({ queryKey }) =>
      request(
        "https://swapi-graphql.netlify.app/.netlify/functions/index",
        document,
        queryKey[1] as unknown
      )
  );
}

Nobody is stopping you from continue using the react-query plugin and we are always open to feedback.

The client-preset was a bold move from our side to increase maintainability and promote GraphQL client best practices such as:

• Document code co-location
• Fragment UI composition

A lot of these concepts are explained in https://the-guild.dev/blog/unleash-the-power-of-fragments-with-graphql-codegen

There are also further features in development that builds upon this foundation such as persisted operations (#8757).