Conditional Logic

The DFBE features a powerful, reactive rules engine that allows you to change field properties (visibility, requirement, state) based on the values of other fields.

1. How it Works

The engine uses a Recursive Logic Tree. Each field can have an array of rules. Each rule consists of a condition (the "If") and one or more effects (the "Then").

Core Concept: Reactivity

Rules are evaluated every time any field value changes. The engine calculates the new state of every field and updates the UI instantly.

2. Rule Structure

{
  "rules": [
    {
      "condition": {
        "type": "condition",
        "field": "has_experience",
        "operator": "eq",
        "value": true
      },
      "effects": [
        { "type": "visible", "value": true },
        { "type": "required", "value": true }
      ]
    }
  ]
}

Supported Operators

Operator	Description	Usage
`eq`	Equal to	`value: "jakarta"`
`neq`	Not equal to	`value: 0`
`in`	Value is in array	`value: ["A", "B"]`
`notIn`	Value is not in array	`value: ["C"]`
`isChecked`	Checkbox is checked	(No `value` needed)
`isNotChecked`	Checkbox is not checked	(No `value` needed)

Note: The isChecked and isNotChecked operators only apply to checkbox type fields.

Edge Case: If the in or notIn operator is used but the target value provided in the schema is not an array, the engine will log a warning. For in it evaluates to false, and for notIn it evaluates to true (making the condition pass).

Supported Effects

Effect	Value Type	Description
`visible`	`boolean`	Shows or hides the field.
`required`	`boolean`	Toggles the mandatory validation.
`disabled`	`boolean`	Enables or disables the input.
`label`	`string`	Changes the field's label text dynamically. Supports `{{fieldName}}` interpolation.
`helperText`	`string`	Changes the helper text dynamically. Supports `{{fieldName}}` interpolation.
`computedValue`	`string`	Sets the field's value from a template or math expression (e.g. `"{{price}} * {{quantity}}"`).

3. Complex Logic (Groups)

You can combine multiple conditions using and or or operators.

{
  "condition": {
    "type": "group",
    "operator": "and",
    "children": [
      {
        "type": "condition",
        "field": "age",
        "operator": "eq",
        "value": 18
      },
      {
        "type": "condition",
        "field": "consent",
        "operator": "isChecked"
      }
    ]
  }
}

Supported operators in condition node: eq, neq, in, notIn, isChecked, isNotChecked. Operators like gt, lt, gte, lte are not supported and will always evaluate to true.

4. Visibility Strategy

Smart Default: The engine automatically applies a "Smart Default" for visibility. If a field only has visible: true rules (and no visible: false rules), the engine automatically treats it as hidden by default. This prevents "Logic Orphan" fields from flickering or appearing before the rules engine has finished its first evaluation.

Explicit Override: If you need to manually control the base visibility (e.g., if you have both visible: true and visible: false rules and want to ensure it starts hidden), you can use the hiddenByDefault: true property in the field definition.

{
  "name": "company_name",
  "hiddenByDefault": true,
  "rules": [
    {
      "condition": {
        "type": "condition",
        "field": "employment_status",
        "operator": "eq",
        "value": "employed"
      },
      "effects": [{ "type": "visible", "value": true }]
    }
  ]
}

5. Deprecated: `visibleIf`

The visibleIf property is a deprecated shorthand for simple single-condition visibility. While it supports most operators (including eq, neq, in, notIn, isChecked, and isNotChecked), it cannot use and/or groups.

{
  "name": "old_field",
  "visibleIf": { "field": "type", "operator": "eq", "value": "special" }
}

Migrate to rules for all new fields. visibleIf will be removed in a future major version.