Redundant resolver types in generated typescript

[samuela]

Description

The outputted TS contains redundant type info.

Steps to reproduce

Here's my schema:

type Query {
  foo(bar: String!): String!
}

Now, I run yarn graphqlgen and check the outputted code in graphqlgen.ts:

export namespace QueryResolvers {
  export const defaultResolvers = {};

  export interface ArgsFoo {
    bar: string;
  }

  export type FooResolver = (
    parent: {},
    args: ArgsFoo,
    ctx: Context,
    info: GraphQLResolveInfo
  ) => string | Promise<string>;

  export interface Type {
    foo: (
      parent: {},
      args: ArgsFoo,
      ctx: Context,
      info: GraphQLResolveInfo
    ) => string | Promise<string>;
  }
}

but this contains two identical typings for the foo resolver: one called FooResolver and another, separate but equivalent definition for QueryResolvers.Type.foo.

Expected results

Something like

export namespace QueryResolvers {
  export const defaultResolvers = {};

  export interface ArgsFoo {
    bar: string;
  }

  export type FooResolver = (
    parent: {},
    args: ArgsFoo,
    ctx: Context,
    info: GraphQLResolveInfo
  ) => string | Promise<string>;

  export interface Type {
    foo: FooResolver;
  }
}

Versions

• graphqlgen: 0.3.0
• OS name and version: macOS 10.14

[schickling]

Thanks a lot for raising this issue. This might be a bit counterintuitive but this is actually intended and a design goal. See here for more details.

TLDR:

Embrace code redundancy. Opposing to the generally desired DRY principle, in the case of generated code, it's more important to be readable and to provide as much context as possible without the need to navigate a lot through the code first. (This also allows for more helpful auto-completion/intellisense.)

[jasonkuhrt]

@schickling I was about to open a similar issue tonight. Luckily saw this one.

it's more important to be readable and to provide as much context as possible without the need to navigate a lot through the code first.

Hm, I don't think I agree that having Type fields be literally code copied instead of references is more readable; Its not what most developers would do and IDE should take care of making peaking references and generally navigating/viewing type data trivial. IMO the systems encoded by generics can also be an agent for simplify type readability; but it needs to be well done.

This also allows for more helpful auto-completion/intellisense.

How so?

[jasonkuhrt]

Related #236

I believe this needs to be reconsidered in light of #428