Yamashou
Allow user override of Operation type
This would allow users to provide their own types in models to be used as response types (basically just prevents it from being generated)
Should we remove the error from the signature, or add an exception for that lint error ?
Thank you for this PR! I think it is problem what generate same operation type. I don’t understand why users can provide thir own types. Please more explanation for me ! I wanna be understand your opinion.
Lets say we have the following:
type User {
id: ID!
name: String!
email: String!
}
query GetUsers() {
getUsers {
id
name
}
}
The schema would generate the User type:
type User struct {
Id string `json:"id"`
Name string `json:"name"`
Email string `json:"email"`
}
And the query would generate the following operation struct:
type GetUsers struct {
GetUsers []*struct {
Id string `json:"id"`
Name string `json:"name"`
} `json:"getUsers"`
}
While that does the job, lets say in the rest of my codebase i need to pass around the User struct, i would have to have some code to transform the unnamed struct to the User type => a lot of boilerplate.
That's where letting the user provide the struct is useful. By adding to my codebase:
type GetUsers struct {
GetUsers []*User `json:"getUsers"`
}
And the relevant models map in the config, that allows me to have the generated client.GetUsers function to return my provided struct that contains an []*User which is way easier to work with.
PS: I have more changes needed to support that behavior than what is in that PR, if we decide to support that, i'll port my changes here (FYI).
I think that method is not good in GraphQL because it also fetches unnecessary fields. You should use a Query and a client that represent the appropriate use case. If you want to get all the fields of User, in any case, I think you need to define all the fields and make it Fragment.
You dont have to fetch all fields, but using in your codebase an unamed struct is a pain
In my example above, User is defined with id, name, email, but I only request 2 of those fields, and imo that's fine to have the last field being at its zero value.
Giving more flexibility, especially for a library can only be a good thing.
I think the meaning is different between the zero value and the absence of the field.
It is, i m not saying that it is the same, using the generated model is a corner case, but what if I just dont want to use an anonymous struct because the result needs to be passed around ? Giving flexbility to the user to control that would be a good idea imo, just like gqlgen does. Lmk if you want that into gqlgenc, otherwise feel free to close that PR, I will be maintaining my own fork as I need that feature, and I m sure other people will.
Do you resolve this problem in this PR ? https://github.com/Yamashou/gqlgenc/pull/66
That would solve half of the concerns I was raising, that #66 is greatly needed, for writing tests for example! I still believe that users should be able to provide their own structs for field responses