Conditions avancées

QForm Builder fournit un éditeur visuel de conditions fondé sur un arbre sérialisable. Un groupe peut contenir des règles ou d’autres groupes, avec une profondeur arbitraire dans les limites de sécurité du package.

Modèle logique

Le moteur manipule un AST JSON composé de deux types de nœuds :

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>
}

Le panneau convertit cet arbre en expression FormKit au moment de la sauvegarde. Le schéma reste donc compatible avec les propriétés existantes :

{
  if: '$age >= 18 && ($country == "FR" || ($country == "MQ" && $consent == true))',
}

Les expressions FormKit prennent en charge les opérateurs booléens, les comparaisons et les parenthèses. Les nœuds conditionnels reçoivent aussi une clé stable dans le runtime du builder.

Groupes ET / OU imbriqués

Dans l’éditeur, chaque groupe peut :

• basculer entre ET et OU ;
• ajouter une règle ;
• ajouter un sous-groupe ;
• déplacer, dupliquer ou supprimer un enfant ;
• contenir plusieurs niveaux de groupes.

Le moteur applique par défaut les limites suivantes :

{
  maxDepth: 8,
  maxNodes: 200,
}

Ces limites évitent les arbres excessifs lors de l’import ou de l’édition.

Éditeurs adaptés au type de champ

Le composant de valeur est choisi à partir du champ référencé :

Type du champ	Éditeur
texte, URL, e-mail	texte
numérique, slider	nombre
checkbox, toggle	booléen
date	date
heure	heure
date/heure	datetime-local
couleur	sélecteur QColor
select	liste des options
multiselect	sélection multiple

Les opérateurs sont eux aussi filtrés selon le type. Par exemple, les comparaisons numériques ne sont pas proposées à une checkbox, et les opérateurs commence par / se termine par sont réservés aux valeurs textuelles.

Opérateurs disponibles

Le moteur couvre notamment :

• vide / non vide ;
• égal / différent ;
• supérieur, supérieur ou égal, inférieur, inférieur ou égal ;
• contient, commence par, se termine par ;
• vrai / faux ;
• aujourd’hui, demain, hier, après-demain et avant-hier.

Simulateur en direct

L’onglet Simulateur affiche uniquement les champs référencés par la condition. Il permet de :

1. reprendre les valeurs courantes du formulaire ;
2. remplacer temporairement une ou plusieurs valeurs ;
3. voir immédiatement le résultat vrai/faux ;
4. inspecter l’expression FormKit générée ;
5. parcourir une trace récursive indiquant la valeur réelle, la valeur attendue et le résultat de chaque groupe ou règle.

Les valeurs du simulateur ne modifient pas les données réelles du formulaire.

API publique

Le sous-chemin conditions expose le moteur pur :

import {
  createQFormBuilderConditionTree,
  evaluateQFormBuilderConditionTree,
  formatQFormBuilderConditionNode,
  buildQFormBuilderConditionFields,
  normalizeQFormBuilderConditionTree,
  parseQFormBuilderConditionExpression,
  serializeQFormBuilderConditionTree,
} from '@vevedh/qform-builder-layer/conditions'

Exemple d’évaluation côté application :

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)
}

Renommage et suppression des champs

Le store analyse les références avec le parseur AST :

• renommer un champ réécrit uniquement les références exactes ;
• supprimer un champ retire les règles qui le ciblent ;
• les conditions des champs, des validations, des attributs disabled / readonly et des étapes sont prises en charge ;
• les autres règles de l’expression sont conservées.

Cette stratégie remplace les recherches textuelles partielles, qui pouvaient confondre deux noms proches.

Compatibilité et sécurité

Le parseur accepte les expressions générées par le builder ainsi que plusieurs expressions historiques simples. En cas d’expression illisible, l’éditeur affiche une erreur et ne remplace pas silencieusement la logique existante.

Les noms de champs sont limités à un format sûr et les segments __proto__, prototype et constructor sont refusés. L’AST est normalisé avant utilisation et les valeurs sont sérialisées comme des littéraux JSON.

Les conditions côté navigateur améliorent l’UX et contrôlent l’affichage. Elles ne constituent jamais une règle d’autorisation : les droits, validations et décisions métier doivent être vérifiés de nouveau côté service Feathers/NFZ.