# Validation

> Required fields, validator rules, custom conditions, and error messages, covering every field of the validator editor.

Source: https://ngxviewbuilder.io/creators/validation

Validation runs when the user submits, when a page changes in stepper mode, and (depending on settings) while editing. Failing elements show their error message and block submission.

**Video lesson 8 (1:44):** [Validation](https://www.youtube.com/watch?v=ZPpFMkTfjkw). Keep bad data out: pattern validators, clear error messages, input masks, and custom validation rules with expressions like dateDiffDays. Chapters: 0:00 Intro, 0:15 Pattern validator, 0:36 Input masks, 0:49 Custom rules, 1:18 Testing validation, 1:30 Recap.

## Required

Turn on **Required** in the Validation section, or use **Require if** for conditional requirement. Set the error text in **Required field message**.

The red asterisk that marks a required field belongs to the label. An element with no label text and no help tooltip renders no label row at all, so the asterisk is not drawn either: floating above an empty space it marks nothing. The field is still required and still validated. When a bare field has to advertise that it is mandatory, give it a label, or say so in its placeholder or description.

## The validator editor

The **Validators** property holds a list of rules. Click **Add validator** to create one; each rule has these fields:

| Field | What it does |
| --- | --- |
| **Type** | Which check to run, see the table below. |
| **Value** | The rule's setting (a length, a bound, a pattern…). |
| **Error message** | Shown when this rule fails. Each rule carries its own message. |
| **Condition (error when true)** | For `custom` rules: an expression that flags an **error while it is true**. |
| **Apply if (optional)** | A guard expression: the whole rule is checked only while this is true. |

| Type | Checks | Example value |
| --- | --- | --- |
| `required` | value present | - |
| `minLength` / `maxLength` | text length | `3` / `50` |
| `min` / `max` | numeric bounds | `0` / `100` |
| `pattern` | regular expression | `^[0-9]{9}$` |
| `email` | email format | - |
| `strictOptions` | value exists in the option list | - |
| `custom` | your own condition | see below |

The list can be longer in your application: developers can register named rules such as *LT personal code* or *IBAN*, which then appear in **Type** exactly like the built-ins. See [custom validator types](https://ngxviewbuilder.io/developers/custom-validators). A rule shown as `(not registered)` comes from a view built in another application that had such a rule; it is skipped until that application registers it.

## Custom validators

A `custom` rule is a true/false [expression](https://ngxviewbuilder.io/creators/expressions) that describes the **error**: the message shows while the condition is true. You can write it directly or put it together on the **Visual builder** tab (field, rule and value per row, matching all or any of them); see [Building a rule without writing it](https://ngxviewbuilder.io/creators/conditional-logic#building-a-rule-without-writing-it).

```text
dateDiffDays({startDate}, {endDate}) < 1        error: end date not after start
{password} != {passwordRepeat}                  error: fields don't match
{advance} > {total}                             error: advance exceeds total
len({phone}) > 0 && !startsWithAny({phone}, "+370")   error: filled but wrong prefix
```

The last pattern (*filled AND wrong*) makes a rule optional: it only fires once the user typed something.

**Apply if** solves the same thing declaratively: set *Apply if* to `len({phone}) > 0` and the condition to `!startsWithAny({phone}, "+370")`.

## When validation runs

**Validation execution mode** (per element, in *Execution modes*) controls the trigger:

| Mode | Validates |
| --- | --- |
| `onBlur` (default) | when leaving the field |
| `onChange` | when the value changes |
| `onInput` | on every keystroke |

## Input masks vs. validators

Masks (Text element) *prevent* wrong input while typing; validators *check* afterwards. For strict formats use both: a `date` mask plus a `pattern` validator.

## Error summary

**Form settings → Show validation issues modal** lists all failing fields in a dialog after a failed submit, which helps on long, multi-page forms.

## Server-side errors

Developers can attach extra errors to any element from the host application (`setElementErrors`), e.g. *"E-mail already registered"* after a backend check. They render exactly like validator errors.

## Good error messages

- Say what is expected, not just "invalid": `Company code is 9 digits`, not `Wrong format`.
- Keep the message next to the rule that triggers it; each validator has its own message.
- For translated views, provide messages in each language via the [Translations](https://ngxviewbuilder.io/creators/translations) tab.