Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export TypedDocumentString #163

Open
jyasskin opened this issue Sep 18, 2024 · 3 comments
Open

Export TypedDocumentString #163

jyasskin opened this issue Sep 18, 2024 · 3 comments

Comments

@jyasskin
Copy link

Right now, if we use documentMode: 'string' the graphql-codegen tool will generate a definition for a TypedDocumentString type into our project. That makes it hard to name the same type from a library like https://github.com/octokit/graphql.js that wants to pass a string through instead of parsing it to a DocumentNode first. It's not obvious that this is the right home for that type, but it seems like the closest existing library.

@fpapado
Copy link

fpapado commented Nov 3, 2024

I have been going down a similar rabbit hole around string-based APIs and standardised types for them (the same octokit issue, in fact!)

I glanced through the original graphql-codegen PR for TypedDocumentString. The decision to inline the type in the output, instead of referencing it from to the core types, seems incidental or at least there was no motivation for it at the time (which is fine 😌).

Having a standard type for string-based libraries (similar to what TypedDocumentNode is for the AST-based APIs) seems like good motivation to me atm.

I have a hunch that we could/should also raise this issue in the graphql-code-generator repository, since that is what would insert the call-sites for this type, and might have more context about its desired shape.


Edit: upon further inspection, DocumentTypeDecoration was added to the core types, as a way to support abstractions over both TypedDocumentNode and TypedDocumentString. The utility types point to that idea as well.

It's probably still good to expose a common TypedDocumentString, but wanted to bring this up 💡

@jasonkuhrt
Copy link

In Graffle I built its own internal typed document abstraction that sons all three cases: graphql package typed document query, this typed document node, and the typed document string.

If there's interest I may open source it after Graffle is released.

It's not much code, it could easily be contributed back also to Guild repos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants