Repository navigation
Mutation namespaces #440
Description
Activity
@ChvilaMartin that's pretty cool. Unfortunately, that's not currently supported. I also don't see any support for this with https://github.com/webonyx/graphql-php. We'd need support there before adding support for that here.
@oojacoboo Webonyx supports it just fine. Or rather no additional support on their side is needed to implement it. I'm using it on another webonyx-based project. Here is how it works:
First I have types like these, representing the mutation namespaces:
final class UserMutationsType extends ObjectType { public function __construct() { parent::__construct([ 'name' => 'UserMutations', 'fields' => function () { return [ 'create' => [ // definition of the create mutation ], ]; }, ]); } }
Next the MutationType needs to use these:
final class MutationType extends ObjectType { public function __construct(ContainerInterface $typeResolver) { parent::__construct([ 'name' => 'Mutation', 'fields' => function () use ($typeResolver) { return [ 'user' => [ 'type' => $typeResolver->get('UserMutations'), 'resolve' => function ($value, $args, $context, ResolveInfo $info) { return []; }, ], ]; }, ]); } }
Easy enough in my opinion.
I've been thinking about this lately and feel like a Namespace Attribute on Controllers would be the most logical.
Imagine:#[GQL\Namespace] class UserController { #[GQL\Query] public function user()... #[GQL\Mutation] public function create()... #[GQL\Mutation] public function update()... #[GQL\Mutation] public function delete()...
Which would result in this Schema:
UserMutations { create()... update().... delete()... }While the user Query is ignored by the Namespace and still directly under the Root Query.
Reacted by Jacob ThomasonReacted by eldr0nIt's actually already possible with current graphqlite. No extra features are necessary, just usage of the existing attributes, mainly ExtendType and Field.
I mean yes its possible, but but hacky.
And the goal of graphqlite is great DX, with the Namespace Attribute it can be backwards compatible and easily added to existing projects with very little work.Reacted by Jacob Thomason@Lappihuan I like the namespace attribute idea. This would create a clean API in GraphQLite.
Reacted by eldr0n@oojacoboo i'd like to base this on the work of #466 should i branch from there or do you see #466 merged soon?
@Lappihuan let's keep it in another branch though. #466 already has way too much in it. I'd really like to keep things separated out. It makes it much easier to focus discussion, reviews and merges. I know it's a bit more work on the PR creation side.
- pinned this issue
on Jun 12, 2022 The PR attempt for adding mutations was closed and not merged. See the PR for additional details and reasoning.
There is an ongoing proposal to add metadata support to the GraphQL spec. This is probably the ideal way of handling this need.
I'm going to leave this ticket open, as the need for some sort of namespace like support still exists.
Hello, hopefully this is not duplication of existing issue.
Is there support for Mutation namespaces like described there: https://graphql-rules.com/rules/mutation-namespaces?
What I want is to be able to have something like this