Can I 'resolve' a mutation's input field/arg?

[rudiedirkx]

Is there a way to 'resolve' a mutation's input field/arg? I want to always define input field/arg notes, but sometimes throw an error, IF it's provided. I can do that in the 'resolve' function of the mutation, but that becomes messy. An optional 'resolve' function would be nice.

I don't see it on https://webonyx.github.io/graphql-php/type-definitions/inputs/ but I might well be missing something. Maybe there's another way to scrutinize input fields per-field?

It's similar to creating a custom ScalarType and implementing parseValue/parseLiteral, but it's not a custom type, it's just a string.

---

Example:

class CreateReservationInput extends ParentInputType {
	function fields() {
		return [
			'resource_id' => [
				'type' => Type::nonNull(Type::int()),
			],
			'date' => [
				'type' => Type::nonNull(GraphQLFactory::create(DateType::class)),
			],
			'start_time' => [
				'type' => Type::nonNull(GraphQLFactory::create(TimeType::class)),
			],
			'end_time' => [
				'type' => Type::nonNull(GraphQLFactory::create(TimeType::class)),
			],
			'notes' => [
				'type' => Type::string(),
				'description' => "Maybe you don't have access to this field",
				// [B]
				'resolve' => function($value) {
					// maybe throw a UserError, or empty the value, or just pass through
					return userHasAccess('notes') ? trim($value) : null;
				}, 
			],
		];
	}
}

class MutationType extends ParentObjectType {
	function fields() {
		return [
			'createReservation' => [
				'args' => [
					'input' => Type::nonNull(GraphQLFactory::create(CreateReservationInput::class)),
				],
				'type' => GraphQLFactory::create(CourtReservationType::class),
				'resolve' => GraphQLAccess::maybe('API_CREATE_RESERVATION', function($root, array $args) {
					// [A]
					if ( !userHasAccess('notes') && !empty($args['input']['notes']) ) {
						$args['input']['notes'] = null;
						// or
						throw new UserError("You can't use 'notes' dude!");
					}
					
					...
				},
			],
		];
	}
}

I know I can check for $args['input']['notes'] in the 'resolve' callback (see [A]), but that's not very clean, and I want to reuse CreateReservationInput so I want to keep it close. So I would like to do some extra input checking in the field definition (see [B]).

[spawnia]

Neither this library nor any other implementation of the GraphQL specification includes such capabilities. It is certainly outside of the specification.

That said, you can take advantage of directives to attach metadata to input object types. Your resolver may then call a generic handler that applies this metadata to the given arguments. I have implemented such a solution, see https://lighthouse-php.com/master/concepts/arg-resolvers.html#motivation for a description and https://github.com/nuwave/lighthouse/tree/master/src/Execution/Arguments for the bulk of the implementation.

[rudiedirkx]

Sorry. I really dislike SOLID. Not people using SOLID. I appreciate your response, but it's not what I'm looking for, I think. I could've said that nicer. Seriously sorry, I didn't mean to be an asshole, I just am sometimes.

I'm hacking a $resolve property into InputObjectField, and using it in Value::coerceValue() (in if ($type instanceof InputObjectType) per $field), but it doesn't feel as good as I'd hoped. Maybe my hacky brain is just trying to make GraphQL into what it shouldn't be.

What's the correct GraphQL way to always expose input field notes, but not always allow values? I want to expose it so the schema is always complete and fully self-documenting. But some API users don't have permission to use that specific input field.

[rudiedirkx]

It can't be directives, right? Because the API client chooses to use a directive, but this isn't up to the client. It's a server-side access check. Or can I add a directive in the schema? :|

[spawnia]

Directives are a generic mechanism to extend the functionality of types. They can be attached basically anywhere within a schema (by server developers) or a query (by clients). That allows enhancing the native InputObjectType of this library naturally, without hacking around in its internals.

Really try and grok https://lighthouse-php.com/master/concepts/arg-resolvers.html#motivation, especially the first link: https://graphql.org/learn/execution. Think about what your inputs are:

• plain input arguments passed by the client
• schema information about the shape of this input

Somehow, you will have to combine those two and derive a generic mechanism for splitting the input and calling different functions on it. Perhaps allowing for multiple levels of nested inputs (that is what I did).

Following that, you may or may not come to similar conclusions as I did. If you want inspiration for a possible solution, consider https://github.com/nuwave/lighthouse/tree/master/src/Execution/Arguments

[spawnia]

To document access control, just use descriptions. There is nothing else that is visible in introspection.

[rudiedirkx]

To document access control, just use descriptions

Yeah, that's why I did for now. And then don't throw errors, but ignore the input. Thanks man. I'll read the docs again. "Argument resolvers" does sound perfect, but it's more complicated than my hack =)