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

An option to disable all the Picks in favor of duplicated type definitions #2020

Closed
ghost opened this issue Jun 19, 2019 · 3 comments
Closed
Labels
plugins waiting-for-release Fixed/resolved, and waiting for the next stable release

Comments

@ghost
Copy link

ghost commented Jun 19, 2019

This may already exist in some form, I've just stated investigating using your library since I love the idea of having customizable templates for our codebase.

Is your feature request related to a problem? Please describe.

This is extremely hard (impossible since not all the info is there) to parse. This is what VS code (and ts cli) shows me as a type (with field names & types redacted, all of the ...s are literally shown to me):

const fieldA: Maybe<{
    __typename: "TypeA";
} & {
    __typename: "TypeA";
} & {
    fieldB: Maybe<{
        __typename: "TypeB";
    } & Pick<TypeB, "c" | "d" | "e" | "f"> & {
        fieldG: {
            __typename: "TypeC";
        } & Pick<...>;
        fieldH: Maybe<...>;
        fieldI: Maybe<...>;
    }>;
} & {
    ...;
} & {
    ...;
} & {
    ...;
} & Pick<...>>

Describe the solution you'd like

The Apollo client:codegen collapses all of these, and the definitions it generates for this exact case are:

export interface TypeA {
  __typename?: 'TypeA';
  fieldA: TypeB | null;
  fieldB: TypeC | null;
  fieldC: TypeD | null;
  fieldD: string | null;
  fieldE: string | null;
  fieldF: string | null;
  ... more fields
}

while this makes the types larger it makes the significantly easier to parse, and since this is all generated code redundancy really isn't an issue.

Describe alternatives you've considered

Additional context

@dotansimha
Copy link
Owner

We are thinking about putting the final evaluated primitive type instead of the Pick<>, this looks very similar.
Thank you for opening this issue :)

@dotansimha
Copy link
Owner

@markkahn #2107 just got merged, and it will be available in the next release.

@dotansimha dotansimha added the waiting-for-release Fixed/resolved, and waiting for the next stable release label Jul 4, 2019
@dotansimha
Copy link
Owner

Available in 1.4.0 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugins waiting-for-release Fixed/resolved, and waiting for the next stable release
Projects
None yet
Development

No branches or pull requests

1 participant