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

feature request: graphql type generation #66

Open
montchr opened this issue Feb 10, 2023 · 3 comments
Open

feature request: graphql type generation #66

montchr opened this issue Feb 10, 2023 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@montchr
Copy link
Sponsor

montchr commented Feb 10, 2023

I've noticed that most if not all of the data returned from GraphQL queries and passed around the application are untyped, resulting in an implicit any type which makes it more difficult to work with the data smoothly and requires setting noImplicitAny in tsconfig.json.

I've also tested out Automattic's boilerplate project in addition to yours. One of the things I liked about the Automattic approach is its use of generated typedefs for (some) queries:

Automattic/vip-go-nextjs-skeleton: A Next.js boilerplate for decoupled WordPress on VIP.

Our boilerplate has a code generation step that examines the GraphQL queries in ./graphql/queries/, introspects your GraphQL schema, and generates TypeScript code that can be used to load data via Apollo. See LatestContent for an example of using generated code with getStaticProps and Post for an example with getServerSideProps.

Having declared types across the entire scope of data fetching chain—queries, responses, and React component props—is incredibly powerful and provides confidence as you build your site. Code generation runs automatically on all GraphQL queries in ./graphql/queries/ whenever you start the development server or build the application.

I see some types manually defined in //apps/nextjs/lib/types.d.ts, but it doesn't seem like they are used much. They also introduce the problem of having manually-defined types for data that we can already get from the GraphQL endpoint -- a divergence from a "single source of truth" for the schema.

From what I gather, it looks like having types generated automatically would be a much more robust approach to a well-typed system using the WPGraphQL schema. It would be great if this project added support for type generation.

Disclaimer: please pardon any ignorant terminology/descriptions I'm using -- I'm a newcomer to GraphQL 😅

@gregrickaby gregrickaby added enhancement New feature or request good first issue Good for newcomers labels Feb 10, 2023
@data-envoy
Copy link

I think this section in the faust.js docs could be helpful in ading this feature. https://faustjs.org/docs/apollo#generating-possible-types-json

@gregrickaby
Copy link
Owner

gregrickaby commented Jan 30, 2024

I spent an entire weekend looking into this via Codegen. https://the-guild.dev/graphql/codegen/docs/getting-started/installation

  1. I was able to wire up Codegen to auto generate types from WP GraphQL. 😄
  2. I was able to import and start using the auto-generated types. 👍🏻
  3. I was not able to commit anything, because this endeavor kicked off an endless rabbit hole of refactors. 👎🏻
  4. I was really surprised that so many types are optional. 🤯
    a. This led to what I consider annoying-looking code like post.title || '' which was required to squelch Typescript warnings everywhere. 😡

TL;DR: I would need to refactor this entire project to use auto generated types. 😢

In hindsight, I should have used this from the start. I love this idea.

@Bjornnyborg
Copy link

@gregrickaby First of all, found your repo today, and got a lot of inspiration from it - great work!

I have a similar private repo in the company where i am working, where we use the auto-generated types - and it's really a great help when building components! So i think this would be a great addition to your project!

A suggestion could be: Start by implementing the auto generated types, and just explicit type everything that isn't typed already. This wouldn't make a difference, since it's already implicitly any.

Then in the future when you refactor parts for other reasons, also implement types as you go. 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants