infinityloop-dev / graphpinator-constraint-directives
Typesystem directives to declare additional validation on top of GraphQL type system.
Installs: 4 262
Dependents: 3
Suggesters: 1
Security: 0
Stars: 3
Watchers: 2
Forks: 2
Open Issues: 7
Requires
- php: >=8.1
- ext-fileinfo: *
- infinityloop-dev/graphpinator: ^1.6
- infinityloop-dev/utils: ^2.3
Requires (Dev)
- infection/infection: ^0.27
- infinityloop-dev/coding-standard: ^0.2
- infinityloop-dev/graphpinator-upload: ^1.1
- phpstan/phpstan: ^1.10
- phpunit/phpunit: ^10.4
Suggests
- infinityloop-dev/graphpinator-upload: Combine Upload type and uploadConstraint directive.
- dev-master
- v1.3.2
- v1.3.1
- v1.3
- v1.2.4
- v1.2.3
- v1.2.2
- v1.2.1
- v1.2
- v1.1
- v1.0.2
- v1.0.1
- v1.0
- v1.0-rc6
- v1.0-rc5
- v1.0-rc4
- v1.0-rc3
- v1.0-rc2
- v1.0-rc1
- dev-dependabot/composer/symfony/process-6.4.14
- dev-dependabot/composer/infinityloop-dev/graphpinator-1.7.5
- dev-dependabot/composer/phpstan/phpstan-1.12.7
- dev-dependabot/composer/infection/infection-0.29.8
- dev-dependabot/composer/phpunit/phpunit-10.5.24
- dev-upload_constraint
This package is auto-updated.
Last update: 2024-11-06 18:15:48 UTC
README
⚡🌐⚡ Typesystem directives declare additional validation on the top of the GraphQL type system.
Introduction
This package allows server to declare additional constraints on accepted values for arguments, fields and input fields. It is also possible for client to declare constraints for variables in request document.
Additional benefit of using constraint directives is that expected values are displayed to client using GraphQL type language in a self-documenting manner.
Installation
Install package using composer
composer require infinityloop-dev/graphpinator-constraint-directives
How to use
In order to enable constraint directives on your server, the only thing you need to do is to put selected directives to your Container
. To avoid cyclic dependencies ConstraintDirectiveAccessor
must be implemented. This step should be automated when using a DI solution.
Here is example configuration for Nette DI:
- Graphpinator\ConstraintDirectives\StringConstraintDirective - Graphpinator\ConstraintDirectives\IntConstraintDirective - Graphpinator\ConstraintDirectives\FloatConstraintDirective - Graphpinator\ConstraintDirectives\ListConstraintDirective - Graphpinator\ConstraintDirectives\ObjectConstraintDirective - Graphpinator\ConstraintDirectives\ListConstraintInput - Graphpinator\ConstraintDirectives\ConstraintDirectiveAccessor( string: Graphpinator\ConstraintDirectives\StringConstraintDirective int: Graphpinator\ConstraintDirectives\IntConstraintDirective float: Graphpinator\ConstraintDirectives\FloatConstraintDirective list: Graphpinator\ConstraintDirectives\ListConstraintDirective object: Graphpinator\ConstraintDirectives\ObjectConstraintDirective listInput: Graphpinator\ConstraintDirectives\ListConstraintInput )
Add constraint to Argument
The most common usage of constraint directives is to validate input from client without having to do it yourself in the resolve function.
$intConstraint; // instance of \Graphpinator\ConstraintDirectives\IntConstraintDirective \Graphpinator\Typesystem\Argument\Argument::create( 'year' \Graphpinator\Typesystem\Container::Int(), )->addDirective( $intConstraint, ['min' => 1900, 'max' => 2021], );
Add constraint to Field
Additional usage of constraint directives is to validate output from your resolve functions.
$intConstraint; // instance of \Graphpinator\ConstraintDirectives\IntConstraintDirective \Graphpinator\Typesystem\Field\Field::create( 'year' \Graphpinator\Typesystem\Container::Int(), )->addDirective( $intConstraint, ['min' => 1900, 'max' => 2021], );
Add constraint to Type & Interface & InputType
Special case is ObjectConstraint
which declares additional information on which fields must be filled. It is a flexible solution to the input-union problem, but can also be applied on Interface/Type to semantically indicate which values are returned.
class DogOrCatInput extends \Graphpinator\Typesystem\InputType { protected const NAME = 'DogOrCatInput'; public funtion __construct( \Graphpinator\ConstraintDirectives\ObjectConstraintDirective $objectConstraint, ) { parent::__construct(); $this->addDirective($objectConstraint, ['exactlyOne' => ['dog', 'cat']]); } protected function getFieldDefinition() : \Graphpinator\Typesystem\Argument\ArgumentSet { return new \Graphpinator\Typesystem\Argument\ArgumentSet([ \Graphpinator\Typesystem\Argument\Argument::create('dog', \Graphpinator\Typesystem\Container::String()), \Graphpinator\Typesystem\Argument\Argument::create('cat', \Graphpinator\Typesystem\Container::String()), ]); } }
Variance
Question of variance comes into play because field, argument, and object constraints can be declared in an interface context and then implemented by the concrete type. Traditional rules apply here.
- Covariance for Field constraints - child can restrict parent's constraint, but may not release it.
- Contravariance for Argument constraints - child can soften parent's constraint, but may not restrict it.
- Invariance for Object constraints - child must contain the same constraint as parent.
Directive options
@stringConstraint
- minLength -
Int
- maxLength -
Int
- regex -
String
- oneOf -
[String!]
- minLength -
@intConstraint
- min -
Int
- max -
Int
- oneOf -
[Int!]
- min -
@floatConstraint
- min -
Float
- max -
Float
- oneOf -
[Float!]
- min -
@listConstraint
- minItems -
Int
- maxItems -
Int
- unique -
Boolean
- innerList - object with the same arguments to recursivelly apply constraint to inner list
- minItems -
@uploadConstraint
- maxSize -
Int
- mimeType -
[String!]
- maxSize -
@objectConstraint
- atLeastOne -
[String!]
- atMostOne -
[String!]
- exactlyOne -
[String!]
- atLeast -
{count: Int!, from: [String!]!}
- atMost -
{count: Int!, from: [String!]!}
- exactly -
{count: Int!, from: [String!]!}
- atLeastOne -