Gqlgen: Input types: cant use methods for setters

Created on 23 Jan 2019 · 10Comments · Source: 99designs/gqlgen

Expected Behaviour

As per https://gqlgen.com/reference/resolvers/ for types to bind to a method, I want to have the same ability for inputs.

Actual Behavior

gqlgen errors out.

Minimal graphql.schema and models to reproduce

It should be possible to define

type SomeInput struct {
    ID string `json:"id"`
}

func (i *SomeInput) SomeField(v string) {
}

to be able to set SomeField: String! through a method.

On a side note: This is one potential solution to #505 because we then know if the field has been specified or not.

enhancement v0.10

Source

danilobuerger

👍4

Most helpful comment

Agreed, I would very much like to see this issue solved as a solution for #505. Is it possible to reopen this @vektah ?

jszwedko on 19 Sep 2019

👍7

All 10 comments

@mathewbyrne @vektah I would like to create a PR for this but I am stuck.

In codegen/util.go I have extended bindObject to also bind to setter methods and set the related fields on Field like bindMethod does for getters.

Now I wonder how to actually generate this. In codegen/type.go the unmarshaling is generated but this is bound to Type not Field so I don't have access to the previous set information on the setter. How should I proceed here?

Extend Type?
Overwrite Unmarshal in Field?
Something else?

danilobuerger on 24 Jan 2019

Make sure you are starting from the next branch, there have been a lot of changes https://github.com/99designs/gqlgen/compare/next

The next thing on my list is to see if TypeReference (formerly Type) can be folded back directly into field, might be better to wait?

vektah on 26 Jan 2019

Sure, can you please ping me when its done so I can start working on this?

danilobuerger on 26 Jan 2019

@vektah any news? I would really like to start with this...

danilobuerger on 5 Feb 2019

The next branch is still in flux, and will be merging into master with the 0.8 release. No specific timeframe but we're thinking the next week or two.

mathewbyrne on 5 Feb 2019

@danilobuerger the large refactor ( #534 ) has landed, make sure you base off next.

vektah on 7 Feb 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.