Skip to content

[Feat] Melt type/build+definition concepts #141

Description

@akomm
Q A
Bug report? no
Feature request? yes
BC Break report? no
RFC? no
Version/Branch ^0.7

I came to an idea, when I was searching for answers. I wanted to know how you modified types like relay-mutation-payload without the requirement to provide build & builderConfig. I found the definition file, but the only way I knew to use it, is to define a builder & builderConfig. Then I found this.

You basically pass some parts of the fields configuration to a given builder as its config.
It looks hard-coded to me - I could not find a way to do it myself just via extension configuration.

Then came the idea:

Why not melt the builder concept and what you do in \Overblog\GraphQLBundle\DependencyInjection\TypesConfiguration into a single concept?

Basically: field Type = builder alias.

Maybe even drop the naming builder and just keep the definition which would make more sense with the unification.

Additionally I'v noticed that you can also map args in field builder. So far I did not find any use case for the args builder. Is there any reason for it to exist at all? The less concepts to achieve the same results, the easier to grok ! :)

Advantages could be:

  • Less configuration/configuration nesting (builder, builderConfig)
  • No hard-coded type normalization like relay-mutation-payload required anymore
  • Users can define types the same way as default bundle types like relay-mutation-payload are currently defined.
  • Less naming confusion (definition/builder) in my opinion (easier to grok )

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions