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

Embedded struct methods are not considered #843

Closed
matiasanaya opened this issue Aug 21, 2019 · 1 comment
Closed

Embedded struct methods are not considered #843

matiasanaya opened this issue Aug 21, 2019 · 1 comment
Labels

Comments

@matiasanaya
Copy link
Contributor

What happened?

Embedded struct methods are not considered by gqlgen when looking at a model. If I'm reading the docs correctly, this should be allowed.

What did you expect?

Embedded struct methods be considered by gqlgen when looking at a model.

Minimal graphql.schema and models to reproduce

type Query {
  todos: [Todo!]!
}

type Todo {
  id: ID!
  name: String!
}
// Todo model
type Todo struct {
	*ider
	*namer
}

// // ID resolver
// func (t *Todo) ID(ctx context.Context) (string, error) {
// 	return t.ider.ID(ctx)
// }
//
// // Name resolver
// func (t *Todo) Name(ctx context.Context) (string, error) {
// 	return t.namer.Name(ctx)
// }

type ider struct{}

func (*ider) ID(ctx context.Context) (string, error) {
	return "1", nil
}

type namer struct{}

func (*namer) Name(ctx context.Context) (string, error) {
	return "name", nil
}

I've commented out the two methods that make gqlgen happy, which are redundant the way I understand go.

You can also clone this repo and run:

cd embedding && go run server/server.go

versions

  • gqlgen version v0.9.1
  • go version go1.12.5 darwin/amd64
  • go modules

Thoughts

Is there a better way of doing what I'm trying to do?

Ideally I'd be able to compose a struct out of other structs or interfaces that I use internally and gqlgen wouldn't force me to define on the composed object all the methods.

But would it be better if gqlgen generated an interface instead of a struct with fields for every type? That way I don't have to be running go generate ./... each time my struct changes and would only depend on the schema.graphql and the gqlgen.yml files.

We are using this in production and I'm wondering if we are using it in the wrong way because I can't seem to understand the use case for this kind of interface:

type TodoResolver interface {
	ID(ctx context.Context, obj *Todo) (string, error)
	Name(ctx context.Context, obj *Todo) (string, error)
}

I'd much prefer this to be generated as:

type TodoResolver interface {
	ID(ctx context.Context) (string, error)
	Name(ctx context.Context) (string, error)
}

Thanks!

@stale
Copy link

stale bot commented Oct 20, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Oct 20, 2019
@stale stale bot closed this as completed Oct 27, 2019
matiasanaya added a commit to matiasanaya/gqlgen that referenced this issue Nov 2, 2019
matiasanaya added a commit to matiasanaya/gqlgen that referenced this issue Nov 3, 2019
matiasanaya added a commit to matiasanaya/gqlgen that referenced this issue Nov 8, 2019
cgxxv pushed a commit to cgxxv/gqlgen that referenced this issue Mar 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant