Apollo-tooling: Fragment types are generated but not referenced in Query types when using codegen:generate to generate typescript

Created on 11 Aug 2018  路  6Comments  路  Source: apollographql/apollo-tooling

This is referring to new apollo NOT apollo-codegen

  • [x] has-reproduction
  • [ ] feature
  • [x] docs
  • [ ] blocking
  • [ ] good first issue

Current behaviour:
While fragment types are generated they are not sued within queries, which leads to:

  • multiple types referencing the same
  • unnecessary complicated type names

For example, the following graphql :

  fragment PartialPost on Post {
    id
  }

  query Posts() {          
    posts {
      ...PartialPost
     }
   }

Will generate:

  • an unnecessary Posts_posts type
  • instead of the Posts referencing the also created PartialPost type
export interface Posts_posts {
  __typename: "Post";
  id: string;
}

export interface Posts {
  posts: (Posts_posts | null)[];
}

export interface PartialPost {
  __typename: "Post";
  id: string;
}

Expected behaviour:

  • The generated query type should reference the generated fragment type instead of creating a duplicate type
has-reproduction 馃摑 documentation

Most helpful comment

Is this being looked into? As @ntziolis says, this issue is a cringe worthy drawback of the apollo typing generator and is a blocking (lack of) feature for moving to apollo.

All 6 comments

How would that work with multiple fragment spreads and other fields?

I see what you are saying. Even in that case I would prefer using Typescript union types vs loosing the information where the fields come from:

export interface Posts {
  posts: ((PartialPost & PartialPost2 & { additional: string})  | null)[];
}

And if the intent is to refer to the union type with a single name you could add a alias:

type Posts_posts = PartialPost & PartialPost2 & { additional: string }

export interface Posts {
  posts: (Posts_posts  | null)[];
}

This wouldn't break the existing implementations, but give more visibility to where certain fields come from + allow all the magic that typescript allows since you retain type information

That said, I can see that some people might prefer it dumped plainly as they are not using typescript and its type system to that extend. As an alternative I would ask to add a flag to tell the generator to enable use of fragment types via unions.

Without it I'm not sure why the fragment type is generated at all if its never supposed to be used given that all queries refer to their own types? I'm sure im just blind to specific use cases right now.

Is this being looked into? As @ntziolis says, this issue is a cringe worthy drawback of the apollo typing generator and is a blocking (lack of) feature for moving to apollo.

I am still hitting this issue but it looks like this was closed.

@jbaxleyiii Was this fixed?

@rebyul and @tomitrescak did you find a work around?

also wondering the status

I'm still getting this issue too

Was this page helpful?
0 / 5 - 0 ratings