eddeee888 / graphql-code-generator-plugins

List of GraphQL Code Generator plugins that complements the official plugins.
MIT License
52 stars 13 forks source link

[FEAT] don't generate resolvers for fields handled by the parent #332

Open laytong opened 1 month ago

laytong commented 1 month ago

When I have a series of types that implement a parent interface. I only want the field resolver to generate for the parent by default.

i.e.

interface Animal {
    id: ID!
    name: String!
    sound: String!
  }

  type Dog implements Animal {
    id: ID!
    name: String!
    sound: String!
    breed: String!
  }

  type Cat implements Animal {
    id: ID!
    name: String!
    sound: String!
    color: String!
  }

  type Query {
    animals: [Animal!]!
  }

when I generate the resolvers. I want to have a top level resolver for say sound defined on Animal but i get empty resolvers generated for Cat and Dog and if i delete them they will just be regenerated everytime I regen for new changes.

Am i missing an existing setting or feature to handle this?

this would be exclusive to interface and implements relationships

Describe alternatives you've considered At the moment i have to rewrite the logic in the child resolver every time.

Additional context I am also making use of Mappers if that has any impact?

laytong commented 1 month ago

Update:

I think what i'm looking for is an option to explicit not auto generate certain keys in the interface because I know i'm using the parent resolver

laytong commented 1 month ago

Related issue also,

For graphs using federation, if I declare a type as defined in another subgraph i.e. i.e. @key(fields: 'id', resolvable: false) This preset still generates the resolvers, even though we actually don't want them.

eddeee888 commented 2 weeks ago

Hi @laytong ,

Apologies, I couldn't get to this earlier.

At the moment i have to rewrite the logic in the child resolver every time.

I think this is the way implementing type resolvers work. In my observations, interfaces don't have field-level resolvers that like types. I believe the generated types may generate resolver types for interfaces which is could be wrong. Let me confirm with the codegen team

For graphs using federation, if I declare a type as defined in another subgraph i.e. i.e. @key(fields: 'id', resolvable: false) This preset still generates the resolvers, even though we actually don't want them.

Good news this bug is fixed in latest version v0.11. Could you please update and try again?

laytong commented 2 weeks ago

Hey, thanks for getting around to this.

Good news this bug is fixed in latest version v0.11. Could you please update and try again?

Awesome i'll check this out.

I think this is the way implementing type resolvers work.

Could be an implementation specific detail? perhaps apollo server specific? I know that if i delete generated child resolver it correctly uses the parent's method. but when there's a child resolver declared it uses that instead (which is the behaviour you'd want)

The frustration for me is that if everytime I regenerate my file, these child resolvers will keep coming back

perhaps this can be resolved with a directive? @inherits or something?

laytong commented 2 weeks ago

So I have the following definition in my schema file as a field on another type

type User @key(fields: "userId", resolvable: false) @tag(name: "internal") {
  userId: ID!
}

it still generates the resolver entry on the new version

import type { UserResolvers } from "./../../types.generated.js";
export const User: UserResolvers = {
  /* Implement User resolver logic here */
};
eddeee888 commented 1 week ago

Hi @laytong , I think if I have a reproducible repo, it would help me understand the issue better. To be honest, Federation support is a bit patchy at the moment, which is something I'm aiming to improve in the upcoming versions 🙂