-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Query
object resolvers type should require only those fields not already required on the mapped type from resolvers
#9887
Comments
Query
object resolvers type should require only those fields not already required on the mapped type for that as resolvers for types at the top levelQuery
object resolvers type should require only those fields not already required on the mapped type from resolvers
Hi @loucadufault ,
To be able to handle more complex cases effectively, we need to be able to do static analysis to compare the mapper against the generated TypeScript type. This can be done most effectively using the TypeScript compiler. However, adding static analysis into the This is why Server Preset (@eddeee888/gcg-typescript-resolver-files) was created. It uses the generated types from In your example, it'd automatically generate resolver files and mark the resolvers that need mappings, and tell the developer why it needs to be implemented: export const Book: BookResolvers = {
author: () => {
/* Book.author resolver is required because Book.author exists but BookMapper.author does not */
},
} Here's another demo where server preset adds required resolvers on mapper type changes: server-preset.movThere's more to features as well, you can read more on how it works and how to set it up here: https://the-guild.dev/graphql/codegen/docs/guides/graphql-server-apollo-yoga-with-server-preset |
Closing this because this is better addressed in Server Preset. If you have issues related to Server Preset, please create an issue in https://github.com/eddeee888/graphql-code-generator-plugins (It's in a separate repo but I'm working closely with the Codegen team) |
Thanks for the reply
Are these actual graphql-js semantics, that it will attempt to call the next resolver if the current one returned an unexpected type?
Can you elaborate on this supposed complexity? To me it just seems like a deep type equality check, I can't imagine that is an unsolved problem in the TypeScript world. As far as checking for all the possible types, since TS types just wrap JS primitives, in this case an object, it comes down to checking properties. I'm mainly not understanding the argument as to why this must be in a separate project; in my view this feature of codegen is fundamentally broken as it stands. |
Sure, here's one of the issues of doing it in base resolver plugin: Generally, to effectively run TypeScript checks we need to load files into compiler's So, here's what we'd need to do:
Apart from running the same logic twice, we need to use This will have performance impact to all existing users.
If you have ideas how to fix issues at the base plugin level, feel free to create a PR 🙂 |
Is your feature request related to a problem? Please describe.
Mappers are useful for situations where the a resolver for a Query field returns a partial object, where some fields are populated by resolvers defined directly on that fields type in the schema.
With this simple schema:
We would define mappers for codegen as:
The issue is that the resolver for the
Book
object in theresolvers
is typed as:avoidOptionals
is falseavoidOptionals
is trueIn this case with the mapped type, neither option is accurate to what is necessary to have a complete implementation of the schema. With it not set, there is no check that the
author
field has any resolver. With it set, there are excess checks for resolvers that are not needed.The more type safe option is to set the option to true, which will require the resolvers for the
Book
object to include a resolver for each field of theBook
type.Describe the solution you'd like
However, codegen knows that every resolver defined in the schema to return an object of the given type, will return an object of the mapped type. Therefore it could generate an appropriate type on the
Resolvers
for that Object type that would require only resolvers for the fields missing from the mapped type. This would be taken as the (recursive) difference between the schema type and the mapped type.In this example, codegen knows that every resolver returning a
Book
Object will return an object of typeBookModel
, therefore missing only the field author, which should be specified on the resolvers for theBook
object type.Alternatively, the config should allow specifying a separate mapped type for the Object type on the
Resolvers
, to at least allow doing this reconcilation manually.Describe alternatives you've considered
Current workaround is to manually type it:
Is your feature request related to a problem? Please describe.
No response
The text was updated successfully, but these errors were encountered: