GraphQL Hook Generation #1091
Unanswered
brentmclark
asked this question in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
This is a continuation of a conversation started in the
react-query
channel on the TANSTACK Discord server today.See the original discussion here
The purpose of this discussion is to talk about the implications of generating hooks using a codegen tool (probably
graphql-code-generator
) that analyzes a graphql schema.For starters, all of the hook generation happening for the
urql
andapollo
plugins ingraphql-code-generator
use the__typename
as a part of the hook name. For example:this schema
would become
... or whatever the hook signature would be. The important part is that the
__typename
from the schema becomes part of the name of the hook.This works well if your cache keys are already using the
__typename
and when the cache keys are static. In RQ, however, there is intentionally no coupling between the cache key and the payload. This is not the standard for client-side caching in GraphQL, but it is the standard for react query. People seem to enjoy this concept of decoupled cache keys; is that something that will remain desirable in a schema-generated world?To summarize my long-winded question:
Should a GraphQL flavor of React Query continue to use a dynamic cache key, or should it lean on the type name from the schema file?
Beta Was this translation helpful? Give feedback.
All reactions