Composants web réactifs

Statut documentaire : guide — voir Maturité et preuves.

Un composant web est l’incarnation web d’un composant UXfc/fonctionnel déclaré. Il doit préserver les mêmes frontières : se lier aux surfaces de données de page, émettre des événements sémantiques locaux et ne franchir les frontières provider/serveur que via des règles d’escalade déclarées.

Contrat

Documenter chaque composant réutilisable avec : nom fonctionnel ; entrées et surfaces de données liées ; état local ; événements émis ; règles d’escalade ; états loading/error/offline ; actions qu’il peut demander. Ce contrat doit rester stable même si l’implémentation de rendu change.

Flux de données

provider / collection
 -> cache DataSet
 -> DataSource ou DataCursor
 -> props/état réactif
 -> rendu du composant

Le composant s’abonne à la surface de page ; il ne doit pas posséder directement le protocole provider ni la transaction de persistance.

État local versus état du modèle

Onglet sélectionné, panneau ouvert, filtre temporaire, texte d’autocomplétion en cours, dropdown ouvert, loading local et valeurs similaires sont de l’état UI local. Elles ne doivent pas devenir silencieusement des attributs conceptuels ou des changements persistés.

Exemples d’escalade

TabSelected reste normalement local. CurrentRowChanged met normalement à jour le contexte local. FilterTextChanged peut être debouncé avant lookup. SearchRequested peut requêter un provider. SaveRequested doit invoquer une action applicative/publiée ou une mise à jour provider. ValidationRequested peut déclencher une action métier ou un processus.

Discipline de performance

Debouncer et batcher les interactions visuelles fréquentes. Les commandes distantes devraient être idempotentes quand c’est possible. Le PageModel, et non le composant, décide quand un événement franchit la frontière Runtime ou service.