Replies: 2 comments 5 replies
-
Is this just a matter of overwriting |
Beta Was this translation helpful? Give feedback.
-
I have done some research and here is what I've learnt. There is a feature request (graphql/graphql-js#1858) for In light of that, looking at solutions like The use-cases for type config decoratorThe use-cases I gathered are:
It also matches with what's requested in graphql/graphql-js#1858. In other words, the overall use-case for type config decorator is to make the schema executable. But that's pretty much all, the decorator shouldn't be used for things like modifying the schema (that's what AST and visitors are for). Type config decorator validationA validation (sanity checks) should be introduced for the decorator to specify how it can manipulate the schema. These rules would apply to both My opinion is that the decorator should be forbidden to touch config options coming from SDL/AST ( Currently, the decorator let you change anything, which in most cases results in an error when the decorator is applied or during execution. I might miss something (comments welcome), but I reckon only these should be allowed:
Rules for schema extendingWith just a limited set of options that can be used with decorators, it's easier to define rules for them. And basically, everything boils down to a single question: what should happen if a config option for a particular type is specified multiple times (in I don't think the schema should anyhow keep track of all values (by creating a stack of them, wrapping them to closure, or whatever the implementation could be). I reckon it should work on the last win principle - the later value simply overwrites the previous one. This simple overwriting should work without problem for most of the options. However, question is, if an error shouldn't be thrown when a value for the particular option already exists. There is no technical reason to do that, it's more a sanity check. I fail to see a valid use case when someone would set for example a field's Some other options (namely $typeConfigDecorator = static function (array $typeConfig): array {
if ($typeConfig['name'] === 'Query') {
$resolveFieldFn = $typeConfig['resolveField'];
$typeConfig['resolveField'] = static function ($source, $args, $context, $info) use ($resolveFieldFn) {
// first handle the fields added by this extension
if ($info->fieldName === 'aNewField') {
return 'a new field value';
}
// then let the existing resolver handle the original fields
return $resolveFieldFn($source, $args, $context, $info);
};
}
return $typeConfig;
}; This is still a WIP, comments are welcome. I'll soon push a PR with tests to see all the above in code. |
Beta Was this translation helpful? Give feedback.
-
What are the (intended) use-cases for type config decorator? There isn't much documentation. And issues usually mention it in relation to enums and custom scalars; nothing much there about resolvers.
My understanding is that the decorator is a remnant from
graphql-js
before v0.12. But even in the older versions, it never was intended for adding resolvers: https://github.com/graphql/graphql-js/blob/v0.11.7/src/utilities/buildASTSchema.js#L126-L127The decorator was intentionally preserved in #248 and @vladar's comment (#248 (comment)) suggests it can be used for resolvers as well.
I have search through the code and issues and there aren't many examples. They usually show code with
resolveFields
(e.g. #163 (comment)), only one shows how to add individual field resolvers (#179 (comment)).But one is more than nothing, so I guess code like this is fine and legal:
The lack of examples makes me wonder. Do people use it in this way at all? Are there any cons & pros comparing to
resolveFields
anddefaultFieldResolver
? Or does everyone build their schema programmatically without SDL? (Personally, in one of my projects I use PHP objects, in the other with SDL I abuse the default resolver to add "middlewares".)Context
The context for this question and the reason why I went down this rabbit hole is the recent addition of
$typeConfigDecorator
toSchemaExtender::extend()
. I made a comment in the PR (#871 (comment)), but there is more to it.Given that the above approach with setting individual field resolves is valid (and that I tested the current
extend()
's behaviour correctly), there is a problem with resolvers for extended types.You can't add a resolver for the field
bye
nor overwriteresolveFields
– the second decorator doesn't run forQuery
type at all:I don't know how much the implementation of
SchemaExtender
aligns with or deviates from the reference implementation, but we can't rely on it much anyway as this "type config decorator" is agraphql-php
specific extension. So we have to decide for ourselves how it should work, what's allowed/supported and what isn't.I'm not sure if technically possible, but the "obvious" solution is to allow for
SchemaExtender
to apply the decorator not only to the new types from the extending document but also to existing types from schema. But then we have to ask how the configs should be merged. And for example, what should happen toresolveField
(which is AFAIK also non-standard extension), because it can't be simply replaced or merged.Use-cases for type config decorator?
Back to my initial question. What are the use-cases for type config decorator?
graphql-js
?)I'm not sure how about alternatives for custom types. But for resolvers, would it be feasible to port
makeExecutableSchema
fromgraphql-tools
? And maybe drop the type config decorator altogether?Beta Was this translation helpful? Give feedback.
All reactions