Patterns and Tips around migrating from Apollo to React Query

[tannerlinsley]

Let's get this going!

[nksaraf]

I recently undertook this migration in my own project and can share some of the things I wrote to make this work. I wanted an API very close to Apollo's to make this easier. There are two files that made it possible. I wrote a sample codesandbox where this code can be played with: https://codesandbox.io/s/peaceful-sun-51609

• graphql-fetch.ts A wrapper around fetch to support graphql requests (this part was essentially taken from prisma-labs/graphql-request). I added a system of middlewares for making stuff like auth easy for me, and potentially more ways to extend in the future.

• react-query-graphql.ts Two hooks useGraphQLQuery and useGraphQLMutation that take gql documents (no query key or query fn required) as arguments. These documents contain all the necessary information to form they key (operation name, variables, etc.). These use a GraphQLProvider to get the url and http options like headers so they don't have to be repeated every time.

This is how its used:

import { GraphQLProvider, useGraphQLQuery } from "./react-query-graphql";
import gql from "graphql-tag";

const POKEMON_QUERY = gql`
  query pokemon($name: String) {
    pokemon(name: $name) {
      id
      number
      name
      attacks {
        special {
          name
          type
          damage
        }
      }
      image
    }
  }
`;

const App = () => {
  const [name, setName] = React.useState("pikachu");
  const { data, error } = useGraphQLQuery(POKEMON_QUERY, {
    variables: { name }
  });
  return (
    <>
      <label>Search for pokemon</label>
      <input
        placeholder="Pokemon name"
        style={{ fontSize: 20 }}
        value={name}
        onChange={e => setName(e.currentTarget.value)}
      />
      <br />
      {data && data.pokemon && (
        <img
          height={100}
          width={100}
          src={data.pokemon.image}
          alt={data.pokemon.name}
        />
      )}
    </>
  );
};

[nksaraf]

Some of my takeaways were:

1. Huge bundle size improvement: Probably lost more than 20 KB in bundle size. (Caveat: In my usage, I removed graphql and graphql-tag in runtime, by processing things at build time using graphq-code-generator to parse and convert gql documents to strings and extracting the operation names and then generating strongly typed hooks like usePokemonQuery (had to write a custom plugin, very similar to apollo's).

2. Caching mechanism is much better for me to reason about and control. With apollo, I would often be stuck figuring out how to make sure my queries are being refreshed when necessary with things like page transitions after mutations.

3. Error handling: I could never properly understand the error handling part of apollo with mutations, when would it throw vs when would it return an { errors } object. I could control things better with react-query since I wrote the graphql error throwing side. Still some polish is required in the graphql code here.

4. No normalized caching: One of Apollo's big value proposition is normalized caching. I didn't have a lot of use of it, since most of my data structures across components were not really overlapping. I don't miss it in my usage right now.

5. Server-side rendering: Apollo has first class support with their getDataFromTree function which traverses the tree and sees what all data is needed, and fetches it on the server side. Needs to be setup at once place only (HOC). With react-query, there is the prefetchQuery option. It's simple to use but not as powerful as apollo's options. We moved to a JAMStack strategy and so this wasn't a major pain point for us.

6. ❤️ Devtools: I like having the console open, and still having the devtools available to me. With apollo have to switch between tabs.

7. Refresh on focus: I really like this feature and wished I had it in apollo.

8. Lazy queries: Apollo has this hook called useLazyQuery that has a useMutation like signature for load queries lazily. I added a skip option to useGraphQLQuery to the same effect. The query is not fetched till its true. It conditionally adds a falsy value to the query key passed down to react-query.

9. API for refetching queries: After mutations occur, other queries need to be refetched and apollo has an option called refetchQueries which would accept an array of queries (operation names only) to refetch after mutation. Right now we are calling refetchQuery in the onSuccess callback, but can probably provide a similar API.

[jedwards1211]

Makes sense, the moment I saw that react-query supports GraphQL requests I was like, huh? Surely it doesn't have some generalized form of normalized caching that works with both GraphQL and other protocols

[tannerlinsley]

The bundle improvements are massive! More than I initially thought they would be. Apollo must be pretty big...

[nksaraf]

Its not a very accurate measure, but I think all of apollo stuff together (apollo-link-http, apollo-cache-inmemory, apollo-client, react-apollo, graphql, graphql-tag) is around 30KB gzipped. I avoid using graphql and graphql-tag, and the rest (react-query, react-query-graphql, and isomorphic-unfetch) is less than 10KB I think. Sorry I haven't measured things well.

[nksaraf]

In their roadmap to 3.0, they are trying to reduce to a 60KB minified size (not gzipped)(https://github.com/apollographql/apollo-client/blob/master/ROADMAP.md), so the difference will probably reduce, we are probably at 20KB minified (with no graphql, graphql-tag)

[elsangedy]

Hi @nksaraf, maybe you can try https://github.com/hasura/graphqurl instead of your own fetch lib, I did a basic example and that seems good, you can check here https://codesandbox.io/s/react-query-graphqurl-ybiop.
Let me know what you think.

[nksaraf]

Hi @elsangedy, Thanks for the suggestion! I did look into this. My concern is that it is using apollo-client as its backend too. (See here https://github.com/hasura/graphqurl/blob/master/src/query.js). It would be redundant for the motives of losing bundle size, using our own cache, etc.

[elsangedy]

@nksaraf I didn't pay attention to that, you're right.

[nksaraf]

But I do think that a simple way to use GraphQL this would be to just use the fetchGraphQL function without all the custom provider, etc.

import { useQuery } from "react-query";
import { fetchGraphQL } from "./graphql-fetch";

const POKEMON_QUERY = `
  query pokemon($name: String) {
    pokemon(name: $name) {
      id
      number
      name
      attacks {
        special {
          name
          type
          damage
        }
      }
      image
    }
  }
`;

function queryResolver(query, variables) {
  return fetchGraphQL("https://graphql-pokemon.now.sh", query, variables);
}

const App = () => {
  const [name, setName] = React.useState("pikachu");
  const { data, error } = useQuery([POKEMON_QUERY, { name }], queryResolver);

  console.log(data, error);
  return (
    <>
      <label>Search for pokemon</label>
      <input
        placeholder="Pokemon name"
        style={{ fontSize: 20 }}
        value={name}
        onChange={e => setName(e.currentTarget.value)}
      />
      <br />
      {data && data.pokemon && (
        <img
          height={100}
          width={100}
          src={data.pokemon.image}
          alt={data.pokemon.name}
        />
      )}
      <pre style={{ color: error ? "red" : "black" }}>
        {JSON.stringify(data ? data : error, undefined, 2)}
      </pre>
    </>
  );
};

[bbuchanan]

Hello. I literally came across Tanner and react-query today and it's fantastic. I have recently started using Apollo client hooks as well in a new project. I am trying to understand what the best course of action might be. Replace Apollo hooks with react-query entirely? Wrap Apollo hooks with react-query where appropriate (would love ideas on their harmonious existence) or maybe I don't need react-query at all?

Thanks for any guidance.

[tannerlinsley]

I would go for a replacement. If you hit any snags I will personally see to it they are addressed.

[bbuchanan]

Does anyone have any recommendations for generating queries and types? With apollo-client, I was using graphql code generator which had an apollo client plugin. With the desire to eliminate apollo-client, what's the best course of action to generate queries/mutations that are consumable by react-query?

[llwt]

You should be able to continue to use graphql-code-generator with a noop gql tag.

We currently use that on a project with that lib as a dev-only dependency.

[bbuchanan]

I figured out a decent way, I think. Hope this helps someone else and also happy to hear of better ways.

I use the following config for graphql-code-generator:

overwrite: true
schema: "http://localhost:4000/graphql"
documents: "src/**/*.graphql"
generates:
  src/generated/graphql.ts:
    plugins:
      - "typescript"
      - "typescript-operations"
      - "typescript-graphql-request"
config:
  rawRequest: true

My graphql endpoint is a simple query that gives a list of states and territories in the USA. The query looks like this:

query States($filter: FiltersExpressionInput, $paging: PaginationArgs) {
  states(filterInput: $filter, paging: $paging) {
    items {
      id
      state
      stateAbbreviation
    }
    total
    hasMore
  }
}

My consuming code looks like this:

import { GraphQLClient } from 'graphql-request';
import React from 'react';
import { useQuery } from "react-query";
import { getSdk } from "./generated/graphql";

function App() {
  const client = new GraphQLClient("http://localhost:4000/graphql")
  const { data, status } = useQuery("states", async () => {
    const sdk = await getSdk(client);
    const states = await sdk.States();
    return states;
  });

  return (
    <div>
      {data ? (<ul>
        {data.data?.states.items.map(x => (<li>{x.state}</li>))}
      </ul>) : "Waiting"}
    </div>
  );
}

export default App;

[kidtango]

I still cant seem to figure out if react-query can handle all of state management needs or not. React Apollo can completely replace other state management tools. It seems like we will have to use Context API or something else to handle client states and store server states when we need to expose them globally?

[tannerlinsley]

Yeah... Apollo let's you use it as a synchronous global state manager. And technically you can do this with React Query too:

// Get some state based on a global key
useQuery('themeMode', () => {}, { initialData: 'light', staleTime: Infinity })

// Set that state
queryCache.setQueryData('themeMode', 'dark')

It's not elegant, because RQ wasn't designed for this. And honestly, neither was Apollo in the beginning. They just decided to tack it on with some plugins. So this is up to you. I personally wouldn't manage my truly global synchronous state in either. But that's your call!

[kidtango]

Hey Tanner, thanks for the reply. Spent a few hours watching youtube vids and RQ and I'm starting to understand it better. I'll give a try! Thanks again.

[arahansen]

In the react-query comparison guide there’s a small blurb about accomplishing auto refetching using a schema and some heuristics on how to consume that schema.

Are there more details on how this works? I’m wondering if this same concept could be used to implement a normalized cache like Apollo. @nksaraf mentioned they don’t utilize the normalized cache much but it’s something I find very useful and would love to see if react-query can support it.

[tannerlinsley]

This is something that could be done externally through a custom hook wrapper of sorts. I haven’t explored it much, mostly because it’s just not that difficult to use the query cache and invalidate queries after mutations yourself. But yeah. It’s possible.

[yss14]

I finally did it! Took me quiet some time, mainly because I also took the opportunity to refactor all the custom data hooks and moved them into a separate package for future reuse, but it was definitely worth it!

Advantages from my side:

• simpler api
• great devtools (I really had problems all the times with the apollo client devtools)
• no bugs at all (at apollo client I regularly stumbled upon bugs which were already reported 2 years ago but still not fixed yet)
• way less bloated and more simpler cache update code
• reduces bundle size

Disadvantages:

• no normalized cache (but I'm not sure if this could also be an advantages; for my use case it works great without)
• maintain my own little graphql client (but also gives me more freedom)

For the implementation side, I took the approach from @nksaraf and changed it a little bit so it perfectly suits my use case.
Client side data was moved to zustand stores.
I further added some typescript logic to define type safe graphql queries and mutations, so I can safely update cache data.

Here's an example:

// QUERY

interface IGetPlaylistsData {
	share: {
		id: string
		playlists: Playlist[]
	}
}

interface IGetPlaylistsVariables {
	shareID: string
}

// definition of the graphql query, so we only have to state the data and variable type once for later inferrence
const GET_SHARE_PLAYLISTS = TransformedGraphQLQuery<IGetPlaylistsData, IGetPlaylistsVariables>(gql`
	query sharePlaylists($shareID: String!){
		share(shareID: $shareID) {
			id,
			playlists {
				${playlistKeys}
			}
		}
	}
`)((data) => data.share.playlists)

// custom query hook using our little graphql client implementation
const useSharePlaylists = (shareID: string, opts?: IGraphQLQueryOpts<typeof GET_SHARE_PLAYLISTS>) => {
	// data and variable type is inferred from the query definition
        const query = useGraphQLQuery(GET_SHARE_PLAYLISTS, {
		variables: { shareID },
		...opts,
	})

	return query
}

// MUTATION

interface ICreatePlaylistVariables {
	shareID: string
	name: string
}

interface ICreatePlaylistData {
	createPlaylist: Playlist
}

const CREATE_PLAYLIST = TransformedGraphQLMutation<ICreatePlaylistData, ICreatePlaylistVariables>(gql`
	mutation createPlaylist($shareID: String!, $name: String!){
		createPlaylist(shareID: $shareID, name: $name){
			${playlistKeys}
		}
	}
`)((data) => data.createPlaylist)

const useCreatePlaylist = (opts?: IGraphQLMutationOpts<typeof CREATE_PLAYLIST>) => {
	const mutation = useGraphQLMutation(CREATE_PLAYLIST, {
		...opts,
		onSuccess: (data, variables) => {
                        // type safe update of our query. No dealing with query keys, they are automatically taken from GET_SHARE_PLAYLISTS 
			typedQueryCache.setTypedQueryData(
				{
					query: GET_SHARE_PLAYLISTS,
					variables: { shareID: variables.shareID },
				},
				(currentData) => [...(currentData || []), data],
			)

			if (opts?.onSuccess) opts.onSuccess(data, variables)
		},
	})

	return mutation
}

For the full implementation details, have a look here.
I'm always looking for feedback and improvements on my approach :)

[gfritzdev]

This is what i'm doing to support GraphQL queries & mutations using react-query.

First I created a reusable fetch function that supports variables. (credentials included because i use httpOnly cookie)

async function fetchData(query, { variables } = {}) {
  const res = await fetch(process.env.NEXT_PUBLIC_GRAPHQL_ENDPOINT, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    credentials: "include",
    body: JSON.stringify({
      query,
      variables,
    }),
  });

  const json = await res.json();
  if (json.errors) {
    const { message } = json.errors[0] || "Error..";
    throw new Error(message);
  }

  return json.data;
}

Heres an example of one of my queries with variables:

export async function getUserLetters(key, { sort, limit, start, where }) {
  const data = await fetchData(
`   
    query USER_LETTERS($sort: String, $limit: Int, $start: Int, $where: JSON) {
      count: userLetterCount
      userLetters(
        sort: $sort
        limit: $limit
        start: $start
        where: $where
      ) {
        id
        title
        slug
        status
        content
        created_at
        updated_at
        __typename
        user {
          id
        }
      }
    }
    `,
    { variables: { sort, limit, start, where } }
  );
  return data?.userLetters;
}

Heres that query in use:

const { data } = useQuery(
    ["userletters", { limit: 2, start: 0 }],
    getUserLetters
  );

I use the same fetch function for mutations:

import { UserFragment } from "../fragments";
/* Sign In Mutation  */
export async function signIn({ identifier, password }) {
  const data = await fetchData(
    `
      mutation signIn($identifier: String!, $password: String!) {
          signIn(input: { identifier: $identifier, password: $password }) {
            authorized
            ${UserFragment}
          }
      }
      `,
    { variables: { identifier, password } }
  );
  return data?.signIn;
}

[balazsorban44]

So you don't even need a library like graphql-request? 😲

UPDATE: After experimenting with it, YES it looks like you do not need any other package than react-query and a wrapper like @gfritzdev provided. I am just curious, why else would you use graphql-request than?

I just removed 50kB(!) of JS by using react-query + custom graphql fetch wrapper, and so far the only down side is that I have to import my queries as strings.

Maybe someone has a solution for that as well? (I have .gql files, and I am now using webpack-graphql-loader to load them as strings)

UPDATE2:
SO I created a webpack loader https://github.com/nhi/graphql-operations-string-loader that can handle multiple operations and exports them as named exports in string format

[michael-land]

custom plugin

// react-query-codegen.js
// react-query-codegen.js
const { concatAST, Kind, visit } = require('graphql');
const {
  ClientSideBaseVisitor,
  indentMultiline,
} = require('@graphql-codegen/visitor-plugin-common');

module.exports = {
  plugin: (schema, documents, config) => {
    const allAst = concatAST(documents.map((v) => v.document));

    const allFragments = [
      ...allAst.definitions
        .filter((d) => d.kind === Kind.FRAGMENT_DEFINITION)
        .map((fragmentDef) => ({
          node: fragmentDef,
          name: fragmentDef.name.value,
          onType: fragmentDef.typeCondition.name.value,
          isExternal: false,
        })),
      ...(config.externalFragments || []),
    ];

    const visitor = new TypeScriptDocumentNodesVisitor(schema, allFragments, config, documents);
    const visitorResult = visit(allAst, { leave: visitor });

    return {
      prepend: visitor.getImports(),
      content: [
        visitor.fragments,
        ...visitorResult.definitions.filter((t) => typeof t === 'string'),
        visitor.queries,
      ].join('\n'),
    };
  },
};

class TypeScriptDocumentNodesVisitor extends ClientSideBaseVisitor {
  constructor(schema, fragments, config, documents) {
    super(schema, fragments, config, {}, documents);
  }
  operations = [];

  buildOperation(
    node,
    documentVariableName,
    operationType,
    operationResultType,
    operationVariablesTypes
  ) {
    this.operations.push({
      node,
      documentVariableName,
      operationType,
      operationResultType,
      operationVariablesTypes,
    });
    return null;
  }

  get queries() {
    return `
    import { QueryConfig, useQuery } from 'react-query';

    function graphql<Result, Variables>(query: string, variables?: Variables) {
      return async (): Promise<Result> => {
        const res = await fetch(process.env.GRAPHQL_API, {
          method: 'POST',
          headers: {
            'Content-Type': 'application/json',
            authorization: \`Bearer \${localStorage.getItem('token')\}\`,
          },
          credentials: 'include',
          body: JSON.stringify({ query, variables }),
        });
    
        const json = await res.json();
        if (json.errors) {
          const { message } = json.errors[0] || 'Error..';
          throw new Error(message);
        }
        return json.data;
      }
    }
    ${this.operations
      .map(({ node, operationResultType, documentVariableName, operationVariablesTypes }) => {
        const optionalVariables =
          !node.variableDefinitions ||
          node.variableDefinitions.length === 0 ||
          node.variableDefinitions.every(
            (v) => v.type.kind !== Kind.NON_NULL_TYPE || v.defaultValue
          );
        const variables = `variables${optionalVariables ? '?' : ''}: ${operationVariablesTypes}`;

        return `
        export const use${operationResultType} = (${variables}, options?:QueryConfig<${operationResultType}>) => 
        useQuery<${operationResultType}, ${operationVariablesTypes}>(
          ['${node.name.value}', variables],
          graphql<${operationResultType}, ${operationVariablesTypes}>(${documentVariableName}, variables),
          options
        )`;
      })
      .map((s) => indentMultiline(s, 2))
      .join(',\n')}`;
  }
}

Config

// config.yml
overwrite: true
strict: true
config:
  avoidOptionals:
    field: true
  scalars:
    _text: string[]
    bigint: number
    date: string
    float8: number
    inet: string
    numeric: number
    timestamptz: string
    uuid: string

  namingConvention:
    typeNames: change-case#pascalCase
    transformUnderscore: true
hooks:
  afterAllFileWrite:
    - prettier --write
schema: graphql.introspect.json
generates:
  src/api.ts:
    config:
      onlyOperationTypes: true
      enumsAsConst: true
      addDocBlocks: false
      preResolveTypes: true
      skipTypename: true
      documentMode: 'string'
    documents:
      - src/**/*.gql
    plugins:
      - typescript
      - typescript-operations
      - react-query-codegen

How to use it

// index.ts
// index.ts
import React from 'react';
import ReactDOM from 'react-dom';
import { useGetBanksQuery } from './api';

export function App() {
  const query1 = useGetBanksQuery({ limit: 3 });
  const query1Clone = useGetBanksQuery({ limit: 3 });
  const query2 = useGetBanksQuery({ limit: 2 });

  // expected only two requests since query1 and query1Clone have same cache key
  return (
    <>
      <div>{JSON.stringify(query1.data?.banks)}</div>
      <div>{JSON.stringify(query1Clone.data?.banks)}</div>
      <div>{JSON.stringify(query2.data?.banks)}</div>
    </>
  );
}

ReactDOM.render(<App />, document.getElementById('root'));```

[dusty]

@xiaoyu-tamu

Thanks for that, it was helpful.

I'm working off of that one and modified it slightly to get mutations in there. Ignore some of the custom error handling in there, that is specific to my queries.

Here is where I'm at right now. Hoping to get the other query functions in there and then work on some sort of auto cache invalidation based on __typenames.

/* eslint-disable @typescript-eslint/no-var-requires */
const { ClientSideBaseVisitor } = require('@graphql-codegen/visitor-plugin-common')
const { concatAST, Kind, visit } = require('graphql')
const autoBind = require('auto-bind')

const fetchGraphqlFn = `
/*
  This function returns a function that is used for doing react-query queries.

  On a Query, the arguments will contain the key prefix (operationResultType)
  followed by the variables.

  On a Mutation, the only argument will be the variables.
*/
export const graphqlFetch = <Result, Variables>(query: string | DocumentNode) => {
  return async (keyPrefixOrVariables: string | Variables, variables?: Variables): Promise<Result> => {
    const queryString = typeof query === "string" ? query : print(query);
    const body = JSON.stringify({ query: queryString, variables: variables ?? keyPrefixOrVariables }, null, 2)
    const res = await fetch(process.env.REACT_APP_GRAPHQL_API || '/', {
      method: 'POST',
      credentials: 'include',
      body,
      headers: {
        'content-type': 'application/json',
        'authorization': \`Bearer \${storage.getItem('token')}\`,
      }
    })
    const json = await res.json()
    if (json.errors) {
      const [error] = json.errors
      const { errorMessage, httpCode, objectType = 'Item' } = error?.extensions || {}
      let message = ''
      if (errorMessage) {
        message = errorMessage
      } else if (httpCode === 404 || message.includes('HttpStatus:404')) {
        message =  \`\${objectType} Not Found\`
      } else if (httpCode === 409 || message.includes('HttpStatus:409')) {
        message = \`\${objectType} Already Exists\`
      } else {
        message = error.message || 'Unknown API Error'
      }
      throw new Error(message)
    }
    return json.data
  }
}
`

const buildQueries = op => {
  const {
    node,
    operationResultType,
    documentVariableName,
    operationVariablesTypes,
    operationType
  } = op
  const variables = node.variableDefinitions
  const isOptional =
    !variables ||
    variables.length === 0 ||
    variables.every(v => v.type.kind !== Kind.NON_NULL_TYPE || v.defaultValue)

  // early return for mutations
  if (operationType === 'Mutation') {
    return `
export const use${operationResultType} = (
  options?: MutationConfig<${operationResultType}>
) => {
  return useMutation<${operationResultType}, Error, ${operationVariablesTypes}>(
    graphqlFetch<${operationResultType}, ${operationVariablesTypes}>(${documentVariableName}),
    options
  )
}`
  }

  /*
    queries will eventually get several methods here
    - useQuery
    - usePaginatedQuery
    - useInfiniteQuery
    - useLazyQuery?
    - useManualQuery? (just return the client?)
  */
  return `
export const use${operationResultType} = (
  variables${isOptional ? '?' : ''}: ${operationVariablesTypes},
  options?: QueryConfig<${operationResultType}>
) => {
  return useQuery<${operationResultType}, Error>(
    ['${operationResultType}', variables],
    graphqlFetch<${operationResultType}, ${operationVariablesTypes}>(${documentVariableName}),
    options
  )
}`
}

class TypeScriptDocumentNodesVisitor extends ClientSideBaseVisitor {
  constructor(schema, fragments, config) {
    super(schema, fragments, config, {})
    autoBind(this)
  }

  operations = []

  buildOperation(
    node,
    documentVariableName,
    operationType,
    operationResultType,
    operationVariablesTypes
  ) {
    this.operations.push({
      node,
      documentVariableName,
      operationType,
      operationResultType,
      operationVariablesTypes
    })
    return null
  }

  getImports() {
    const imports = [
      `import {
  useQuery,
  usePaginatedQuery,
  useInfiniteQuery,
  useMutation,
  QueryConfig,
  QueryResult,
  MutationConfig
} from 'react-query'`,
      `import storage from 'local-storage-fallback'`,
      `import { print, DocumentNode } from 'graphql'`
    ]
    const baseImports = super.getImports()
    return [...baseImports, ...imports]
  }

  get queries() {
    return `
${fetchGraphqlFn}
${this.operations.map(buildQueries).join('\n')}
`
  }
}

module.exports = {
  plugin: (schema, documents, config) => {
    const allAst = concatAST(documents.map(v => v.document))

    const allFragments = [
      ...allAst.definitions
        .filter(d => d.kind === Kind.FRAGMENT_DEFINITION)
        .map(fragmentDef => ({
          node: fragmentDef,
          name: fragmentDef.name.value,
          onType: fragmentDef.typeCondition.name.value,
          isExternal: false
        })),
      ...(config.externalFragments || [])
    ]

    const visitor = new TypeScriptDocumentNodesVisitor(schema, allFragments, config, documents)
    const visitorResult = visit(allAst, { leave: visitor })

    return {
      prepend: visitor.getImports(),
      content: [
        visitor.fragments,
        ...visitorResult.definitions.filter(t => typeof t === 'string'),
        visitor.queries
      ].join('\n')
    }
  }
}

[sushilbansal]

Has anyone tried graphql code generator with React-Query: https://graphql-code-generator.com/docs/plugins/typescript-react-query

I used graphql code generator with apollo and it was really nice experience. I am trying to use it but getting several errors at this moment.

[sushilbansal]

yeah. the problem was i was trying to generate .tsx file and it was causing issues. Once i changed the extension to ts it worked.

[akafaneh]

I'm trying to migrate from Apollo to RQ, i used graphql-code-generator and also want to use it with my RQ setup.
I'm facing a little bit of an issue, I assumed it might be more gql codegen related so i posted it on their discussions
I'm gonna repost it here maybe someone can help me figure it out or point me to how i can work over/around it.
I'm using a custom fetcher which is a hook.

Maybe i'm totally mistaken about this or i'm missing something here.

i have a query:

const getAuthUsers = gql`
  query getAuthUsers($userId: uuid!) {
    authentication_users(where: { uuid: { _eq: $userId } }) {
      uuid
    }
  }
`;

and i'm trying to call the query passing the userId from a state, which can be undefined (have type of string | undefined)

  const [authInfo] = useRecoilState(authAtoms.authInfo);
  const { data } = useGetAuthUsersQuery({ userId: authInfo?.uuid });
  //Here i get an error: Type 'string | undefined' is not assignable to type 'string'.

So my thoughts here for this error is that i should be able to make the whole variables object optional so i can pass the variables after checking that they are actually available

  const variables = !!authInfo?.uuid ? { userId: authInfo?.uuid } : undefined;
  const { data } = useGetAuthUsersQuery(variables);
  //here i still get an error: Argument of type '{ userId: string; } | undefined' is not assignable to parameter of type 'Exact<{ userId: string; }>'.

I found the only way to get over this is make the $userId in my query an optional variable (remove the !) which feels kinda "hacky" to me, I still want the variables to be typed and passed with the right restrictions toward what is optional and what is required, but at the same time i wanna be able (NOT-to-pass)/(condition) the variables object as a whole, in case i'm waiting for some other data/state before calling the query.

My thoughts is that maybe not passing the variable object at all can prevent the query from being executed/called until the variables object is passed (with all the required properties as they will be typed as specified in the gql query operation).

i checked @graphql-codegen/typescript-react-query for an option maybe to enable that, and couldn't find any. now i'm thinking maybe it can an optional thing to enable/disable (the variables object being always optional)?

Or maybe i'm missing another way to do this other of what i mentioned. any help/thoughts are appreciated

Thanks.

[dusty]

you could just set an empty string to bypass the type problem and use enabled to make sure it doesn't fire until the userId is available.

const { data } = useGetAuthUsersQuery({ userId: authInfo?.uuid ?? '' }, {enabled: !!authInfo?.uuid })

[TkDodo]

maybe this helps, don't know how it works with graphql-code-generator though:

https://tkdodo.eu/blog/react-query-and-type-script#type-safety-with-the-enabled-option

[akafaneh]

@dusty i thought of this, but it felt more like a work around and can get annoying on query with big variable object.

[statico]

I would love to have a unified solution for custom type serialization/deserialization on the client and server.

graphql-code-generator's ScalarsMap gets half of the way there. By defining a custom scalar type in codegen.yml, you get custom types and serialization for your resolvers. However, right now, there doesn't seem to be a way to marshal these types on the frontend. There's an open request for it: dotansimha/graphql-code-generator#5949

Specifically, I really only want a Date type so that I can give apollo-server Date objects on the server and get Date objects on the client. Right now I'm passing Unix seconds everywhere -- Math.floor(date / 1000) on the server and new Date(date * 1000) on the client.

[Jayphen]

Has anyone had success with replacing Apollo's getDataFromTree for SSR? Probably using something like https://github.com/FormidableLabs/react-ssr-prepass ? I would like to migrate a (very large) app, and there are hundreds of deeply nested queries that need to be fetched and dehydrated

[zsolt-dev]

Looking for the same answer...

#3270