Conditions

Conditions let you control dynamic behavior across the schema. You can use them to show/hide fields, make fields read-only, disable inputs, trigger reactive changes, or validate values.

A condition compares a value from the form data (property) against an expected value or rule (value, expectation, etc.) using an assertion or an expectation.

---

Basic structure

{
  "property": "age",
  "assertion": "isAbove",
  "value": 17
}

The condition will be true if the user entered a value above 17 for age.

You can define the logic in two ways:

• With an assertion: using Chai assertion syntax
• With an expectation: using Chai expectation syntax

They are functionally equivalent. Choose one or the other (not both).

---

Keys available

Key	Description
property	The path to a field in the form data.
assertion	The condition type to apply using Chai assertions.
expectation	Alternative to assertion, using Chai expectations.
value	The value to compare against.
value.from	Pull value from another field instead of hardcoded.
propertyAs	Force interpretation of property value as a type (e.g. number, age, yearsFrom, bool, etc.).

---

Most used assertions

Assertion	Description
isTrue	Value is true.
isFalse	Value is false.
equal	Strictly equal value.
notEquals	Strictly not equal.
isAbove	Greater than value.
isBelow	Less than value.
includes	Array includes a given element.
excludes	Array does not include a given element.
matches	Value matches a regex pattern.
existsAndNotEmpty	Custom assertion: value must exist and not be empty, null, undefined or NaN.

tip

All available assertion operators are listed in the Chai assert API.

tip

If you're using expectation instead, refer to the Chai expect API.

---

existsAndNotEmpty

existAndNotEmpty is a custom assertion added because ChaiJS exists does not check for empty strings.

For example, in this data:

{
  "policy_owner": {
    "first_name": ""
  }
}

A condition with assertion: "exists" on policy_owner.first_name would return true — but as a user, we expect this to be invalid.

Use existAndNotEmpty to ensure the value:

• is not null,
• is not undefined,
• is not NaN,
• is not an empty string || array || object.

Using propertyAs

Some assertions need type coercion. For example, turning a birthdate into an age:

{
  "property": "birthdate",
  "propertyAs": "age",
  "assertion": "isAbove",
  "value": 17
}

Other possible values: number, bool, date, yearsFrom, monthsFrom, etc.

---

Comparing two fields

Use value.from to compare two fields dynamically:

{
  "property": "years_of_exp",
  "assertion": "isBelow",
  "value": { "from": "age" }
}

You can use propertyAs on either field to enforce types.

---

Combining multiple conditions

Conditions can be wrapped in an array and combined with an operator:

[
  { "property": "age", "assertion": "isAbove", "value": 17 },
  { "property": "country", "assertion": "equal", "value": "FR" },
  { "operator": "and" }
]

Use operator: "or" to change the logic. The operator must be the last element of the array.

---

Conditional conditions

In some advanced cases, a condition itself might need to be enabled or disabled depending on other data. This can be done by adding a conditions array inside another condition object.

This allows you to make a condition active only when another condition is met.

{
  "property": "age",
  "assertion": "isAbove",
  "value": 17,
  "condition": [
    {
      "property": "is_minor_mode",
      "assertion": "isFalse"
    }
  ]
}

In this example, the age check (isAbove 17) will only be evaluated if the property is_minor_mode is false. If the nested conditions are not met, the entire condition is ignored.

This is particularly useful when:

• a validation should only apply under specific modes,
• a visibility rule should not trigger in certain contexts,
• or when multiple logical layers are needed.

---

Where conditions are used

• visible: Show/hide fields or groups.
• readOnly: Prevent editing.
• disabled: Disable input and exclude from data.
• validations: Enforce rules (with message).
• onValueChange: Add conditional logic.

Each field accepts a boolean, a single condition, or an array of conditions.

---

Conditions inside arrays

When working with Multiple Input Groups (such as array, or multi iterations), it is often necessary to define conditions that apply to a specific item within the list, rather than to the entire array.

For example, you may want to show or validate a field only if another field within the same row (or item) meets a certain condition.

---

Example

Consider the following data:

{
  "vehicles": [
    {
      "is_second_hand": true,
      "purchase_price": 0
    }
  ]
}

We might want the field purchase_price to be visible only if the corresponding is_second_hand field is set to true.

To achieve this, we can use the special placeholder [x] inside the condition path.
This placeholder dynamically refers to the current index of the item being evaluated.

{
  "purchase_price": {
    "component": "price",
    "label": "Purchase price",
    "visible": [
      {
        "property": "vehicles[x].is_second_hand",
        "assertion": "isTrue"
      }
    ]
  }
}

At runtime, [x] is replaced by the current index of the item:

• For the first item → vehicles[0].is_second_hand
• For the third item → vehicles[2].is_second_hand

This allows each element of the array to evaluate its own condition independently.

---

How it works

• The [x] token acts as a contextual placeholder within conditions.
• It is automatically replaced by the item’s index in the array.
• It can be used anywhere in the property path where an index would normally appear.
• Conditions using [x] are evaluated per item, ensuring that visibility, validation, or any other condition remains scoped to that item.

---

Typical use cases

• Visibility rules within tables or array-based inputs
  Example: Show a price field only when a checkbox is selected in the same row.
• Validation conditions based on another value within the same item.
  Example: Validate a field only if a specific flag in that same element is active.
• Dynamic enable/disable logic applied per element.
  Example: Disable a field if another field in the same item meets a certain rule.

---

Notes

• The [x] placeholder only works within the same array context.
• It can be used in all condition-based keys: visible, readOnly, disabled, validations, onValueChange, etc.
• If you use nested arrays, each level has its own [x] corresponding to the current loop depth.

---

In summary:
Use [x] in your condition paths to create contextual, per-item logic inside Multiple Input Groups. This allows you to control the behavior of fields dynamically for each element in a list or table.

For a deeper dive, check:

• Validations
• Visibility
• onValueChange