Advanced conditions
QForm Builder provides a visual condition editor backed by a serializable tree. A group may contain rules or other groups, allowing recursive logic within the package safety limits.
Logical model
The engine uses a JSON AST with two node types:
interface QFormBuilderConditionRule {
id: string
kind: 'rule'
field: string
operator: QFormBuilderConditionOperator
value: QFormBuilderConditionValue
}
interface QFormBuilderConditionGroup {
id: string
kind: 'group'
combinator: 'and' | 'or'
children: Array<QFormBuilderConditionGroup | QFormBuilderConditionRule>
}The panel converts this tree into a FormKit expression when it is saved, so the schema remains compatible with the existing properties:
{
if: '$age >= 18 && ($country == "FR" || ($country == "MQ" && $consent == true))',
}FormKit expressions support boolean operators, comparisons, and parentheses. Conditional nodes also receive a stable runtime key.
Nested AND / OR groups
Each group can:
- switch between AND and OR;
- add a rule;
- add a nested group;
- move, duplicate, or remove a child;
- contain multiple nested levels.
Default safeguards are:
{
maxDepth: 8,
maxNodes: 200,
}They prevent excessive trees during import and editing.
Type-aware value editors
The referenced field determines the value editor:
| Field type | Editor |
|---|---|
| text, URL, e-mail | text |
| number, slider | number |
| checkbox, toggle | boolean |
| date | date |
| time | time |
| date/time | datetime-local |
| color | QColor picker |
| select | option list |
| multiselect | multiple selection |
Operators are filtered by field kind as well. Numeric comparisons are not offered for a checkbox, while starts with and ends with are limited to textual values.
Available operators
The engine includes:
- empty / not empty;
- equal / not equal;
- greater than, greater than or equal, less than, less than or equal;
- contains, starts with, ends with;
- true / false;
- today, tomorrow, yesterday, day after tomorrow, and day before yesterday.
Live simulator
The Simulator tab displays only fields referenced by the condition. It can:
- load current form values;
- temporarily override one or more values;
- show the boolean result immediately;
- display the generated FormKit expression;
- render a recursive trace with actual value, expected value, and the result of each rule and group.
Simulator values never change the real form data.
Public API
The conditions subpath exposes the pure engine:
import {
createQFormBuilderConditionTree,
evaluateQFormBuilderConditionTree,
formatQFormBuilderConditionNode,
buildQFormBuilderConditionFields,
normalizeQFormBuilderConditionTree,
parseQFormBuilderConditionExpression,
serializeQFormBuilderConditionTree,
} from '@vevedh/qform-builder-layer/conditions'Application-side evaluation example:
const parsed = parseQFormBuilderConditionExpression(
'$age >= 18 && ($country == "FR" || $country == "MQ")',
)
if (parsed.valid) {
const evaluation = evaluateQFormBuilderConditionTree(parsed.tree, {
age: 32,
country: 'MQ',
})
console.log(evaluation.result)
console.log(evaluation.trace)
}Field rename and removal
The store resolves references through the AST parser:
- renaming a field rewrites exact references only;
- removing a field removes rules that target it;
- field conditions, conditional validation,
disabled/readonly, and step conditions are supported; - unrelated rules remain intact.
This replaces partial string searches that could confuse similar field names.
Compatibility and security
The parser accepts expressions generated by the builder and several simple legacy expressions. When an expression cannot be parsed, the editor reports the error and does not silently replace the existing logic.
Field names use a guarded format, and the __proto__, prototype, and constructor segments are rejected. The AST is normalized before use and values are serialized as JSON literals.
Browser-side conditions improve UX and control visibility. They are never an authorization mechanism: permissions, validation, and business decisions must be enforced again in the Feathers/NFZ service.