Graphqlbundle: Type-Builder

Created on 7 Feb 2018  路  10Comments  路  Source: overblog/GraphQLBundle

| 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'}
        # ...
enhancement

All 10 comments

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

Was this page helpful?
0 / 5 - 0 ratings