| Q | A
| ---------------- | -----
| Bug report? | no
| Feature request? | yes
| BC Break report? | no
| RFC? | no
| Version/Branch | dev-master
Being able to create type builders, like done here:
https://github.com/overblog/GraphQLBundle/blob/bee5671564fe57c10b7686f55ad6e57afd3505fa/Relay/Connection/ConnectionDefinition.php
would save a lot of configuration boilerplate. Currently it is encapsulated inside own _types extension and it seems to me not accessible from outside as consumer.
Example this:
Mutation:
someMutation:
type: 'SomeMutationPayload!'
args:
input: {type: 'SomeMutationInput!'}
SomeMutationInput:
type: 'input-object'
config:
fields:
name: {type: 'String!'}
# ...
SomeMutationPayload:
type: 'object'
config:
fields:
success: {type: 'SomeMutationSuccessPayload'}
failure: {type: 'SomeMutationFailurePayload'}
SomeMutationSuccessPayload:
type: 'object'
config:
fields:
result: {type: 'SomeResultType'}
# ...
SomeMutationFailurePayload:
type: 'object'
config:
fields:
_error: {type: 'String'}
name: {type: 'String'}
With the abilities to define types like in the linked config mapper for the relay connection, would enable me to implement a builder for this:
Mutation:
someMutation:
builder: 'my-mutation-builder'
builderConfig:
name: 'SomeMutation'
inputFields:
name: {type: 'String!'}
# ...
successFields:
result: {type: 'SomeResultType'}
# ...
failureFields:
_error: {type: 'String'}
name: {type: 'String'}
# ...
Sorry but I don't really get it, what do you want to do with type builder exactly?
Something like this as definition mapper:
use Overblog\GraphQLBundle\Definition\Builder\MappingInterface;
final class MutationDefinition implements MappingInterface
{
public function toMappingDefinition(array $config)
{
$mutationName = $config['name'];
$inputFields = $config['inputFields'];
$successFields = $config['successFields'];
$failureFields = $config['failureFields'];
return [
'field' => [
'type' => $mutationName . 'Payload!',
'args' => [
'input' => $mutationName . 'Input!',
],
],
'types' => [
$mutationName . 'Input' => [
'type' => 'input-object',
'config' => [
'fields' => $inputFields,
],
],
$mutationName . 'Payload' => [
'type' => 'object',
'config' => [
'fields' => [
'success' => ['type' => $mutationName . 'SuccessPayload'],
'failure' => ['type' => $mutationName . 'FailurePayload'],
],
],
],
$mutationName . 'SuccessPayload' => [
'type' => 'object',
'config' => [
'fields' => $successFields
],
],
$mutationName . 'FailurePayload' => [
'type' => 'object',
'config' => [
'fields' => $failureFields,
],
],
],
];
}
}
Usage, given 'my-mutation-builder' is the name for the above mapper:
Mutation:
type: 'object'
config:
fields:
someMutation:
builder: 'my-mutation-builder'
builderConfig:
name: 'SomeMutation'
inputFields:
name: {type: 'String!'}
# ...
successFields:
result: {type: 'SomeResultType'}
# ...
failureFields:
_error: {type: 'String'}
name: {type: 'String'}
# ...
Result:
Mutation:
type: 'object'
config:
fields:
someMutation:
type: 'SomeMutationPayload!'
args:
input: {type: 'SomeMutationInput!'}
SomeMutationInput:
type: 'input-object'
config:
fields:
name: {type: 'String!'}
# ...
SomeMutationPayload:
type: 'object'
config:
fields:
success: {type: 'SomeMutationSuccessPayload'}
failure: {type: 'SomeMutationFailurePayload'}
SomeMutationSuccessPayload:
type: 'object'
config:
fields:
result: {type: 'SomeResultType'}
# ...
SomeMutationFailurePayload:
type: 'object'
config:
fields:
_error: {type: 'String'}
name: {type: 'String'}
This is just an example of how I would use it, but it would enable everyone to implement own convention for own projects.
I still don't get it, but this is not a big deal feel free to propose a PR, this will become a little more concrete...
I will come back to this with a PR. I have checked the processor workings and I think it is doable. But I will only have time in a few days to do so :)
Thank you we will add this to 0.12 milestone :+1: give you some more time to work on this
Any news on this?
Yeah, it would be great feature.
I try to find time to revisit this guys. Currently on too many fronts and can only do this in free time.
@coolmic @IgorSzymanski finally got my hands on this, WIP
implemented with #473