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

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

Open
laytong opened this issue Sep 24, 2024 · 6 comments
Open

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

laytong opened this issue Sep 24, 2024 · 6 comments
Assignees

Comments

@laytong
Copy link

laytong commented Sep 24, 2024

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
Copy link
Author

laytong commented Sep 25, 2024

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
Copy link
Author

laytong commented Oct 8, 2024

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
Copy link
Owner

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
Copy link
Author

laytong commented Oct 31, 2024

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
Copy link
Author

laytong commented Nov 1, 2024

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
Copy link
Owner

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 🙂

@eddeee888 eddeee888 self-assigned this Nov 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants