@graphql-directive/core
Advanced tools
Comparing version 0.0.1-alpha.32 to 0.0.1-alpha.35
{ | ||
"name": "@graphql-directive/core", | ||
"version": "0.0.1-alpha.32+efba1a1", | ||
"version": "0.0.1-alpha.35+26c02a7", | ||
"description": "GraphQL directive core functions", | ||
@@ -12,8 +12,2 @@ "main": "./lib/index.js", | ||
}, | ||
"exports": { | ||
"./validator": { | ||
"main": "./lib/validator.js", | ||
"types": "./lib/validator.d.ts" | ||
} | ||
}, | ||
"keywords": [ | ||
@@ -59,3 +53,3 @@ "graphql", | ||
}, | ||
"gitHead": "efba1a1c043d96ec6920be0ba58ea70aa82de321" | ||
"gitHead": "26c02a7f60d5265851e75944ca6cf8641f86844d" | ||
} |
106
readme.md
@@ -1,2 +0,2 @@ | ||
# GraphQL Directive Core Functions | ||
# Authorization Directive | ||
@@ -6,105 +6,1 @@ [![Node.js CI](https://github.com/ktutnik/graphql-directive/actions/workflows/test.yml/badge.svg)](https://github.com/ktutnik/graphql-directive/actions/workflows/test.yml) | ||
Provides reusable functions for adding directive functionality to a GraphQL schema using schema transformation. It contains basic building blocks that can be used by other packages to easily incorporate directive functionality into their own GraphQL schemas. With this library, developers can easily define custom directives with specific functionality, such as authorization or caching, and seamlessly integrate them into their GraphQL schema. This library is designed to streamline the process of working with GraphQL directives, making it easier for developers to add powerful functionality to their GraphQL APIs. | ||
## Extending Validation Logic | ||
To create a custom validation directive, you need to provide two things: The plugin that is your own validation implementations to extend the validation core, and the directive schema. | ||
The plugins are a list of functions that will be used to validate the field value. It's important to note that the plugins don't need to provide the logic to traverse through the object fields because the core validator takes care of that. Instead, each plugin is responsible for validating a specific field or argument. | ||
The directive schema, on the other hand, is used to define the custom validation directive itself. This includes specifying the directive name, its arguments, and the locations where it can be used. By defining the directive schema, you can ensure that your custom validation directive is integrated properly into your GraphQL schema. | ||
## Example | ||
As an example, let's create a custom validation directive that leverage the functionality of the Validator.js library. In this example, we'll create a @validate directive with two methods: EMAIL and LENGTH. | ||
The EMAIL method will validate that a given field value is a valid email address, while the LENGTH method will validate that a given field value is a string with a length between a minimum and maximum value. | ||
```typescript | ||
import val from "validator" | ||
import { createValidatorTransformer, Plugins } from "@graphql-directive/core" | ||
// plugins, the logic to validate field | ||
const plugins:Plugins = { | ||
EMAIL: (str, { directiveArgs: args }) => val.isEmail(str) | ||
|| args.message | ||
|| `Must be a valid email address`, | ||
LENGTH: (str, { directiveArgs: args }) => val.isLength(str, ctx.directiveArgs) | ||
|| args.message | ||
|| `Must be a string or array between ${args?.min ?? 0} and ${args?.max}`, | ||
} | ||
// the validation directive schema | ||
const typeDefs = ` | ||
enum ValidationMethod { | ||
EMAIL, LENGTH | ||
} | ||
directive @validate( | ||
method: ValidationMethod!, | ||
message: String, | ||
validator: String, | ||
min:Int, | ||
max:Int | ||
) repeatable on INPUT_FIELD_DEFINITION | ARGUMENT_DEFINITION | ||
` | ||
// transformer function that will glue the directive with the validation logic | ||
const transform = createValidatorTransformer({ plugins, directive: "validate" }) | ||
``` | ||
The plugins are a key-value object consisting of plugin method names and their validation logic | ||
```typescript | ||
{ | ||
METHOD: (value, ctx) => isValid(value) | ||
|| ctx.directiveArgs.message | ||
|| "The error message" | ||
} | ||
``` | ||
`args` : Is the argument passed from the `@validate` directive, for example `@validate(method: LENGTH, min: 1, max: 150)`, the `args` parameter will contains `{ min: 1, max: 150 }`. | ||
`option`: Is the transformer options, contains some useful information such as list of plugins, directive name (for custom directive name), and list of custom functions. | ||
Validator is a function with signature like above with below parameters: | ||
* `value`: Is the value that will be validate | ||
* `ctx`: Is the validation context, it contains more detail information required for custom validation. | ||
* `options` : Contains options values of transformer | ||
* `path` : The location of where validator applied from the root path through the GraphQL fields | ||
* `contextValue` : An object shared across all resolvers that are executing for a particular operation. Use this to share per-operation state, including authentication information, dataloader instances, and anything else to track across resolvers. | ||
* `parent` : The return value of the resolver for this field's parent (i.e., the previous resolver in the resolver chain). | ||
* `args` : An object that contains all GraphQL arguments provided for this field. | ||
* `info` : Contains information about the operation's execution state, including the field name, the path to the field from the root, and more. | ||
* `directiveArgs` : Contains argument passed by the @validate directive. For example `@validate(method: LENGTH, min: 1, max: 150)`, the `args` parameter will contains `{ min: 1, max: 150 }`. | ||
The return value is `true | string` | ||
The directive schema should reflect the plugin functionalities such as the method name and its parameters. Like example above we providing the enum for the method and list of supported parameters. | ||
```graphql | ||
enum ValidationMethod { | ||
CUSTOM, EMAIL, LENGTH | ||
} | ||
directive @validate( | ||
# the method name | ||
method: ValidationMethod!, | ||
# the custom validator | ||
validator: String, | ||
# for custom message | ||
message: String, | ||
# list of all plugin parameters | ||
min:Int, | ||
max:Int | ||
) repeatable on INPUT_FIELD_DEFINITION | ARGUMENT_DEFINITION | ||
``` | ||
The last step is creating the transform function by calling the `createValidatorTransformer`. The first parameter is the plugins and the last parameter is the name of the directive in this case is `validate`. | ||
> IMPORTANT | ||
> | ||
> * `CUSTOM` on `ValidationMethod` is required | ||
> * Top 3 parameters (`method`, `validator`, `message`) are required to add. |
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Empty package
Supply chain riskPackage does not contain any code. It may be removed, is name squatting, or the result of a faulty package publish.
Found 1 instance in 1 package
Major refactor
Supply chain riskPackage has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.
Found 1 instance in 1 package
Manifest confusion
Supply chain riskThis package has inconsistent metadata. This could be malicious or caused by an error when publishing the package.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Manifest confusion
Supply chain riskThis package has inconsistent metadata. This could be malicious or caused by an error when publishing the package.
Found 1 instance in 1 package
2711
3
0
6
3