Currently, gql.tada is an alternative to codegen tools, which generate types, like the client-preset.
Instead of assigning pre-generated types to GraphQL documents, they're instead parsed and inferred in TypeScript’s type system itself. However, this increases tsc type checking time at least linearly with the amount of documents a user writes and creates.
While this also is a problem with codegen tools (the time of tools run in parallel in a watch mode, or ahead of time, will increase as well), the processing that type inference takes will almost always be much larger.
Instead of always inferring the type of GraphQL documents, we could instead allow graphql() to lookup pre-computed types, which are created ahead of time.
This would mean that graphql() has two ways of looking up a type for a given document:
It first checks whether a cache contains the query its been passed and uses that type if it's available
If not; it falls back to inferring the type of the given document on the fly
The CLI would be used to populate the cache that graphql() reads from (#76). This is dependent on the CLI having an implementation to discover documents, which is necessary for #77 anyway.
tl;dr: This means that a user can, after they're done editing queries and getting type updates in real-time, run the CLI and commit ahead-of-time-precompiled types for all queries.
Since this is a transparent optimisation, this is like a turbo mode for gql.tada and merges the approaches of codegen and inferred GraphQL types and creates a seamless bridge.
This should also alleviate performance problems when compared to other codegen approaches indefinitely.
Proposed Solution
gql.tada has a global, declaration-based queries cache with types
graphql() can lookup types in this cache and use them
The CLI has a command (name TBD) to generate this cache
Context
Currently,
gql.tadais an alternative to codegen tools, which generate types, like theclient-preset.Instead of assigning pre-generated types to GraphQL documents, they're instead parsed and inferred in TypeScript’s type system itself. However, this increases
tsctype checking time at least linearly with the amount of documents a user writes and creates. While this also is a problem with codegen tools (the time of tools run in parallel in a watch mode, or ahead of time, will increase as well), the processing that type inference takes will almost always be much larger.In #150, we've experimented with printing internal types from TypeScript in the CLI.
Summary
Instead of always inferring the type of GraphQL documents, we could instead allow
graphql()to lookup pre-computed types, which are created ahead of time.This would mean that
graphql()has two ways of looking up a type for a given document:The CLI would be used to populate the cache that
graphql()reads from (#76). This is dependent on the CLI having an implementation to discover documents, which is necessary for #77 anyway.tl;dr: This means that a user can, after they're done editing queries and getting type updates in real-time, run the CLI and commit ahead-of-time-precompiled types for all queries.
Since this is a transparent optimisation, this is like a turbo mode for
gql.tadaand merges the approaches of codegen and inferred GraphQL types and creates a seamless bridge.This should also alleviate performance problems when compared to other codegen approaches indefinitely.
Proposed Solution
gql.tadahas a global, declaration-based queries cache with typesgraphql()can lookup types in this cache and use them