Graphql-code-generator: Mapper types don't apply everywhere they should for typescript-resolvers

Created on 13 Dec 2018  路  7Comments  路  Source: dotansimha/graphql-code-generator

Describe the bug
Hey all, I opened a task for this a month ago, but I think the test case isn't quite right. Sorry for disappearing there, I went offline for thanksgiving and this fell off my radar. I can fix, but I want to confirm that this is actually a problem and I'm not missing something.

Test case addition for #886
https://github.com/dotansimha/graphql-code-generator/commit/b1bf6983522211a0432392ff3d8cea6b014e98dc?diff=unified

So let's say I'm writing a resolver using apollo-server for the following schema's mutation:
https://github.com/dotansimha/graphql-code-generator/blob/master/packages/plugins/typescript-resolvers/tests/typescript-resolvers.spec.ts#L779-L789

// Assume I have mapper from Post to PostEntity
const resolvers: { RootMutation: RootMutationResolvers.Resolvers } = {
  RootMutation: {
    async upvotePost(id) {
      // ... perform mutation code
      // reload entity
      const post = await PostEntity.findOne({ id });

     // This is a type error using the generated code
     // as UpvotePostPayload is presumably: (see 2 below)
      return { post };
    }
  }
} 

UpvotePostPayload is presumably here:

export interface UpvotePostPayload {
  post?: Maybe<Post>;
}

... but then I have to return Post in my upvotePost function, not PostEntity. Apollo handles nested resolvers fine.

What I expect this to essentially be, for RootMutationResolver is, notice the changes:

- export interface UpvotePostPayload {
+ export interface UpvotePostPayload<T = Post> {
-  post?: Maybe<Post>;
+  post?: Maybe<T>;
}

export namespace RootMutationResolvers {
  export interface Resolvers<Context = {}, TypeParent = {}> {
-     upvotePost?: UpvotePostResolver<Maybe<UpvotePostPayload>, TypeParent, Context>;
+    upvotePost?: UpvotePostResolver<Maybe<UpvotePostPayload<PostEntity>>, TypeParent, Context>;
  }

-  export type UpvotePostResolver<R = Maybe<UpvotePostPayload>, Parent = {}, Context = {}> = Resolver<R, Parent, Context, UpvotePostArgs>;
+ export type UpvotePostResolver<R = Maybe<UpvotePostPayload<PostEntity>>, Parent = {}, Context = {}> = Resolver<R, Parent, Context, UpvotePostArgs>;
    export interface UpvotePostArgs {
      id: string;
    }
  }

... as things stand now, I would have to map PostEntity to Post in this mutation, with all of Posts required fields filled in.

bug plugins waiting-for-release

All 7 comments

We want to resolve an object that fits a custom interface ResolvedUser when User type is used then we need to duplicate and update all the types making them separated from typescript-server.

type Feed {
  articles: [Article]
}

type Article {
  author: User
  title: String
  text: String
}

type User {
  id: ID
}

type Query {
  feed: Feed
}

The Feed interface says we will return an array of Article and those objects has User and that object should be replaced with ResolvedUser. That means we need to duplicate and point Feed to a copy of Article that points to ResolvedUser.

So I guess we would need to find those types and duplicate them or duplicate everything.

@dotansimha

@kamilkisiela What about something like https://github.com/dotansimha/graphql-code-generator/pull/1139?

I only thought about enums when I made it (since that was where my problem was), but the approach could be extended to other types as well. Do you think something like that could solve your problem too?

@SirensOfTitan Did you ever find a solution to this one?

It's going to be fixed in the upcoming release, right @dotansimha ?

Fix available in 1.0.0 馃憤

Hmm @dotansimha: mapper types still don't seem to apply in the case I listed above with 1.0.0.

(Really really appreciate all of your hard work with this library by the way!)

@SirensOfTitan Can you please open a new issue for that? I think it should be easier to fix now in 1.0

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rogerg93 picture rogerg93  路  3Comments

edorivai picture edorivai  路  3Comments

iamdanthedev picture iamdanthedev  路  3Comments

jackhkmatthews picture jackhkmatthews  路  3Comments

steebchen picture steebchen  路  3Comments