-
-
Notifications
You must be signed in to change notification settings - Fork 821
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
Add inheritResolversFromInterfaces option #720
Add inheritResolversFromInterfaces option #720
Conversation
bf9e1af
to
3e01db4
Compare
3e01db4
to
0b1931f
Compare
inheritResolversFromInterfaces
option
cc @benjamn =) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good so far! Just a few suggestions regarding options parameter style.
src/schemaGenerator.ts
Outdated
resolverValidationOptions: IResolverValidationOptions = {}, | ||
inheritResolversFromInterfaces: boolean = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than adding another boolean positional argument, let's merge the validation options and the resolver inheritance option into a single options parameter. This will probably require a more general name for the IResolverValidationOptions
type, such as IAddResolveFunctionsToSchemaOptions
.
More on why boolean positional arguments are problematic: https://ariya.io/2011/08/hall-of-api-shame-boolean-trap
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I completely agree but I was avoiding making a breaking change to the public api. I'll see about supporting call signatures with a warning as discussed on twitter.
@@ -69,6 +69,7 @@ function _generateSchema( | |||
allowUndefinedInResolve: boolean, | |||
resolverValidationOptions: IResolverValidationOptions, | |||
parseOptions: GraphQLParseOptions, | |||
inheritResolversFromInterfaces: boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This boolean argument is fine because _generateSchema
is private to this module (and not exported like addResolveFunctionsToSchema
).
src/schemaGenerator.ts
Outdated
const typeNames = new Set([ | ||
...Object.keys(schema.getTypeMap()), | ||
...Object.keys(resolvers) | ||
]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little simpler?
const typeNames = Object.keys({
...schema.getTypeMap(),
...resolvers,
});
Having an array rather than a Set
should be fine because the only usage below is calling forEach
.
src/schemaGenerator.ts
Outdated
return; | ||
} | ||
|
||
const interfaceResolvers = (type as GraphQLObjectType).getInterfaces().map((iFace) => resolvers[iFace.name]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might be able to reorganize this code so that the type.getInterfaces()
call is inside a type instanceof GraphQLObject
conditional block, so you don't have to explicitly cast it. Then you could put the code above in the else
branch and avoid the early return
, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I love returning early!
But I also see what you mean and this is a much cleaner suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated with a new interface
src/schemaGenerator.ts
Outdated
resolverValidationOptions: IResolverValidationOptions = {}, | ||
inheritResolversFromInterfaces: boolean = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I completely agree but I was avoiding making a breaking change to the public api. I'll see about supporting call signatures with a warning as discussed on twitter.
src/schemaGenerator.ts
Outdated
return; | ||
} | ||
|
||
const interfaceResolvers = (type as GraphQLObjectType).getInterfaces().map((iFace) => resolvers[iFace.name]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I love returning early!
But I also see what you mean and this is a much cleaner suggestion.
(working on docs but welcome a review on the changes) |
Added some docs about the new api and rebased |
This adds `inheritResolversFromInterfaces` to `addResolveFunctionsToSchema` and `makeExecutableSchema` Later on we'll want to support interfaces implementing other interfaces graphql/graphql-spec#295
8906bed
to
302e1a6
Compare
schema: options, | ||
resolvers: legacyInputResolvers, | ||
resolverValidationOptions: legacyInputValidationOptions | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
🎉 |
This adds
inheritResolversFromInterfaces
toaddResolveFunctionsToSchema
andmakeExecutableSchema
Later on we'll want to support interfaces implementing other interfaces
graphql/graphql-spec#295
TODO: