Problem

Default scalars don't provide specific validation or convey the meaning for certain fields.

Overview

WPGraphQL currently provides the following Scalars, based on the default Scalars defined by the GraphQL Spec:

• Int: A signed 32‐bit integer.
• Float: A signed double-precision floating-point value.
• String: A UTF‐8 character sequence.
• Boolean: true or false.
• ID: The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache. The ID type is serialized in the same way as a String; however, defining it as an ID signifies that it is not intended to be human‐readable.

Default Scalars Don't Convey Meaning

The typed nature of GraphQL Schemas allow for fields to convey meaning with the Type the field returns.

An email field, for example, is indeed a String, but it's a specific type of string with specific validation rules. By having the email field return email Type instead of string, this conveys meaning to clients of the intent of the field.

This would allow tooling to use Introspection and determine what field types to use for Mutations, for example. If an input field had the type email, a client form library could use that from Introspection to render an email input field with client validation, etc.

Custom Scalars will allow fields to convey more meaning and open up new possibilities for client applications to better understand and interact with the WPGraphQL API.

Default Scalars Don't Provide Specific Validation / Sanitization

Often times fields need specific validation/sanitization for specific inputs.

Right now, any field that's declared a string must handle specific validation/sanitization in the resolver. This can lead to a lot of duplicate code.

For example, if an email address were expected as input for a 5 different User mutations, because it's a string, the validation to ensure it's a valid email address must happen in all 5 mutation resolvers that accepts the email input.

By introducing Custom Scalars, validation/sanitization can be defined once for the Custom Scalar, and applied anywhere a field of type EmailAddress were used in the Schema.

This can reduce a lot of duplicate code and allow enforce more strict validation/sanitization in many places.

Proposal

Introduce new Custom Scalars for common data types used by WordPress.

Some initial ideas included:

• Date
• Time
• DateTime
• EmailAddress
• URL
• HTML
• HexColorCode

Once these Scalars are added to the type system, we'd need to update fields and inputs in the Schema to use these Scalars.