-
Notifications
You must be signed in to change notification settings - Fork 225
I would like to make the current user easily available in resolvers, for instance, so that I can filter entities by the current user.
I think one supported way would be to add the user to the context, but I would like to have it in a "more typesafe" and less verbose form in the resolvers, so I wondered if something like ControllerArgumentResolvers exists for resolvers.
All reactions
Replies: 1 comment 5 replies
All reactions
Thanks, that's already helpful for that specific case :D 👍
I'm still trying to read if there's a way to inject additional arguments to the resolvers/providers 🤔
All reactions
i use this:
* @GQL\Mutation(name="userCreate") * @GQL\Access("hasPermission('user', 'CREATE')") */ public function __invoke(UserCreate $input): UserCreatePayload { return new UserCreatePayload( $input->clientMutationId, $this->commandBus->handle($input) ); }
where
/** * @GQL\Input(isRelay=true) */ final class UserCreate { use RelayInputTrait; /** * @GQL\Field(type="String!") */ public string $username; /** * @GQL\Field(type="String") */ public ?string $plainPassword; /** * @GQL\Field(type="String") */ public ?string $email; }
All reactions
But in that case this needs to be supplied in the GQL query, right?
I'm more looking for something like what https://symfony.com/doc/current/controller/argument_value_resolver.html is for controllers.
All reactions
try https://github.com/overblog/GraphQLBundle/blob/0.13/docs/definitions/type-system/scalars.md#custom-scalar ... use string value to find entity in DB...
All reactions
But in that case again we need to send the string value in the GraphQL query, which makes sense when we are for instance updating the user.
But what about when we're talking about a query/mutation where we don't want to supply the user - an example could be a query "give me all blog posts of the current user" - in that case we don't want to pass the user as an argument, but rather fetch it from symfonys security system. But I'd like to avoid doing that in every provider, I'd rather prefer having that similarly to how the User-Controller-Argument-Resolver does that for symfony controller.