How to exclude empty types when using fragments?

[gopeter]

I'm building an app with a Craft CMS GraphQL API and Next.js and have defined this query:

query GetHomepage($language: String!) {
  homepage: entry(uri: "__home__", site: [$language]) {
    ... on homepage_homepage_Entry {
      id
      title
      pageContent {
        ... on pageContent_wysiwyg_BlockType {
          wysiwyg
        }
      }
    }
  }
}

Looking at this query, it's clear that the type can only be homepage_homepage_Entry. But the code generator generates this one:

export type GetHomepageQuery = {
	__typename ? : 'Query',
	homepage: Maybe <{
		__typename ? : 'pages_pages_Entry'
	} | {
		__typename ? : 'homepage_homepage_Entry',
		id: Maybe < string > ,
		title: Maybe < string > ,
		pageContent: Maybe < Array < Maybe < {
			__typename ? : 'pageContent_wysiwyg_BlockType',
			wysiwyg: Maybe < string >
		} >>>
	} > 
};

So I'm not able to access my data just like this: homepage.pageContent, because pageContent does not exist here: { __typename ? : 'pages_pages_Entry' }.

Is there anything that I can configure to remove { __typename ? : 'pages_pages_Entry' } from the generated type? For sure entry could be of type pages_pages_Entry, but I do not query any fields from it and therefore do not need this Union here.

[dotansimha]

I'm not sure that homepage_homepage_Entry is the only type possible. How does entry field is defined?
Basically, codegen tried to reflect the whole possible response from the server, based on the schema. If there is a need for a fragment - it means that you might have interface/union, and your schema might return other types as well.

[dotansimha]

But what if in runtime, the server will return you a different type? That makes the type-safety redundant. If your schema is able to return more than just a single type, your client code should adjust to that.
If you don't query something - the server can still return it.
In this specific case - it can return either pages_pages_Entry or homepage_homepage_Entry. It's better to check it in the client than trying to workaround that, since if it will be returned and you'll ignore it- you'll get an empty object.

[gopeter]

Hmmm, not sure I understand what you mean, since the client just asks for one specific type – why should the server return a different type? 🤔 Since I can‘t query types which aren‘t defined (because of Graphql‘s type safety). Maybe I‘m missing something, but if I ask for homepage_homepage_Entry explicitly, I do not expect that I could get a pages_pages_Entry

[dotansimha]

The client doesn't ask for a specific type. For the client it's: if the type homepage_homepage_Entry is returned, give me these fields: .... Setting inline fragment doesn't add a filter for the returned data.

[gopeter]

But ...

homepage: entry {
  ... on homepage_homepage_Entry {
    id
    title
  }
}

... won't return anything if the type is not homepage_homepage_Entry.

I still don't really get why the above query could be anything other than:

export type GetHomepageQuery = {
    __typename ? : 'homepage_homepage_Entry',
    id: Maybe < string > ,
    title: Maybe < string > ,
};

Well, I don't think that this is something that can be solved easily (or rather be solved at all), so thanks for this great tool and thanks for your answers! I think I have to create some TypeScript helpers which extracts the part of the returned typed with the typename I expect. Something like this.

[dotansimha]

As I said before, inline fragments are not filters. They are just a specification of the fields you wish to get, in case that type is being returned.

If you have:

interface Node {
  id: ID!
}

type A implements Node {
  id: ID!
  a: String
}

type B implements Node {
   id: ID!
   b: String
}

type Query {
  node: Node!
}

And you do:

query {
   node {
      ... on A {
         id
         b
      }
   }
}

The possible return value for that query is { __typename: "B" } | { __typename: "A", id: string, b: string }. The server can still return B here, because the fragment is not a filter.

The logic in the server might return only A, but the schema declares that it can return any Node, so you should handle this case as well.

Your options here as I can see it:

1. Ignore all types that you don't care about - but note that you might get it anyway since it's not a filter.
2. If your backend and resolvers know to filter based on fragments specified (using info parameter) - then you can safely assume that filter will work.
3. Change your schema to return a concrete type and not an abstract type.

[zo-ly]

I am upgrading the codegen version in my project from 1.1.3 to 2 and have encountered a lot of typescript compatibility issues.

My problem is similar to this discussion. I found that the v1.1.3 can exclude these empty types, but the v2 can't. Is there any way now to exclude these empty types?

Here is the code demonstration. Thank you very much for this tool.