-
Notifications
You must be signed in to change notification settings - Fork 142
docs: Custom error messages in the input schema #2121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,112 @@ | ||
| --- | ||
| title: Custom error messages | ||
| description: Learn how to define custom error messages for input validation in your Actor's input schema. Make validation feedback clearer and more user-friendly. | ||
| slug: /actors/development/actor-definition/input-schema/custom-error-messages | ||
| --- | ||
|
|
||
| **Learn how to define custom error messages for input validation in your Actor's input schema. Make validation feedback clearer and more user-friendly.** | ||
|
|
||
| --- | ||
|
|
||
| When an input fails validation against an Actor's input schema, the resulting errors are processed and displayed to the user. By default, these messages are generic and may not clearly convey the specific semantic meaning behind validation rules. | ||
|
|
||
| Custom error messages allow Actor developers to define tailored feedback messages for input validation errors, making it easier for users to understand what is required and improving overall usability. | ||
|
|
||
| ## The problem with generic error messages | ||
mfori marked this conversation as resolved.
Show resolved
Hide resolved
mfori marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Some validation rules defined by Actor developers carry specific semantic meaning that cannot be clearly conveyed by generic error messages. | ||
|
|
||
| For example, consider the following input field using the `pattern` validation keyword: | ||
mfori marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ```json | ||
| { | ||
| "title": "Email address", | ||
| "type": "string", | ||
| "description": "Your email address", | ||
| "editor": "textfield", | ||
| "pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$" | ||
| } | ||
| ``` | ||
|
|
||
| Input that don't satisfy the pattern, will produce an error message like: | ||
mfori marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ```text | ||
| Field "email" should match pattern "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$". | ||
| ``` | ||
|
|
||
| However, a message such as the following would be much more understandable for the user: | ||
|
|
||
| ```text | ||
| Field "email" must be a valid email address. | ||
| ``` | ||
|
|
||
| ## Using the `errorMessage` keyword | ||
mfori marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| Each property in the [input schema](./index.md) can include an `errorMessage` field that defines custom error messages to be displayed when validation of that field fails. | ||
mfori marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| The `errorMessage` must be an object that maps *validation keywords* (e.g., `type`, `pattern`, `minLength`) to their respective custom messages. | ||
|
|
||
| ```json title="Email input with custom error messages" | ||
| { | ||
| "title": "Email address", | ||
| "type": "string", | ||
| "description": "Your email address", | ||
| "editor": "textfield", | ||
| "pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$", | ||
| "errorMessage": { | ||
| "type": "Email must be a string", | ||
| "pattern": "Email must be a valid email address" | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| If a validation error occurs for a keyword that is not listed in the `errorMessage` object, the system will fall back to the default error message. | ||
|
|
||
| ::::note | ||
| Custom error messages are especially useful for complex validation rules like regular expressions, where the default error message would show the entire pattern, which is not user-friendly. See [best practices](#best-practices) for more guidance. | ||
| :::: | ||
mfori marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ### Supported validation keywords | ||
|
|
||
| You can define custom error messages for any validation keyword supported by the [input schema](./index.md), including: | ||
|
|
||
| | Type | Supported validation keywords | | ||
| |--------------------|-----------------------------------------------------------------------------| | ||
| | `string` | `type`, `pattern`, `minLength`, `maxLength`, `enum` | | ||
| | `number`/`integer` | `type`, `minimum`, `maximum` | | ||
| | `boolean` | `type` | | ||
| | `array` | `type`, `minItems`, `maxItems`, `uniqueItems`, `patternKey`, `patternValue` | | ||
| | `object` | `type`, `minProperties`, `maxProperties`, `patternKey`, `patternValue` | | ||
|
|
||
| #### Nested properties | ||
|
|
||
| It's possible to define custom error messages in sub-properties as well. For objects with nested properties, you can define error messages at any level of nesting: | ||
|
|
||
| ```json | ||
| { | ||
| "title": "User", | ||
| "type": "object", | ||
| "description": "Provide user details", | ||
| "editor": "schemaBased", | ||
| "properties": { | ||
| "email": { | ||
| "type": "string", | ||
| "pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$", | ||
| "errorMessage": { | ||
| "pattern": "Please enter a valid email address" | ||
| } | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## Best practices | ||
|
|
||
| While custom error messages can improve the user experience by providing clearer guidance, it's generally better to rely on the default error messages unless there's a specific need for customization. Only use custom error messages when they significantly help users understand the requirements better than the default messages. | ||
|
|
||
| If you do decide to use custom error messages, follow these best practices: | ||
|
|
||
| 1. **Be specific** - Clearly explain what is required or what went wrong | ||
| 2. **Be concise** - Keep messages short and to the point | ||
| 3. **Be helpful** - Provide guidance on how to fix the issue | ||
| 4. **Be consistent** - Use a similar tone and style across all messages | ||
|
||
Uh oh!
There was an error while loading. Please reload this page.