Message et contrat

Gabarit de chaque page de référence : la règle, pourquoi elle existe, l'exemple tiré du chat, le contre-exemple et ce que le broker dit alors.

La règle

Un message est une enveloppe à clé unique { nom: { payload } }. Le payload est de la donnée JSON pure, et tout champ est déclaré au catalogue. Deux clés d'enveloppe sont réservées au framework, id et session : jamais dans un payload ni au catalogue.

Pourquoi

Un message doit se comporter à l'identique livré localement (copie structuredClone) ou à travers un canal (JSON.stringify). Une Date, une instance, une fonction ne survivent pas au second. Et si un champ non déclaré pouvait passer, le catalogue ne décrirait plus rien.

Dans le chat

La date est une string ISO, contrainte par un pattern dans le contrat de message_poste.

Contre-exemple

this.broker.publish(this, { message_demande: { ref, texte, auteur: "alice" } });

ERROR (broker): message_demande v1 r0 from ecran_fil invalid — dropped: - auteur: field not declared in catalog (R1)

JSON pur

Cinq types : string, number (fini), boolean, object, array. Pour une date : un timestamp number ou une string ISO. Pour un handle (socket, pool) : jamais en message, au constructeur.

Révision, version, émetteur, abonné

Une révision est une évolution compatible (ajout de champs), gravée en snapshot complet. La courante est la plus haute ; le moteur la dérive.
Un émetteur déclare la révision qu'il produit et est validé contre elle. Omise, c'est la courante.
Un abonné ne déclare jamais de révision : il reçoit toujours la forme canonique, complétée par les default.
Une version est un changement cassant, rare, avec un upcastFrom déclaratif. Évolution des contrats.

Le broker est strict

Inscription en bloc et atomique : message, version ou révision inconnus, collision d'instanceName, objet sans instanceName : l'objet entier est rejeté, register renvoie false, l'application continue sans lui. Jamais d'exception.
Payload invalide jeté à l'émission, violations listées en console.
Catalogue linté à la construction du broker : types, fields/items manquants, pattern/enum/default incohérents, oneOf fautif, . dans un nom de champ, upcastFrom malformé, et la garantie de forme canonique.
Un contrat validé ne se modifie jamais : on révise ou on versionne.

ERROR (broker): acces_demande v2 is not in the catalog ERROR (broker): registration of ecran_connexion rejected as a whole — nothing registered (see errors above)

Plusieurs clés dans une enveloppe

Le broker tolère plusieurs noms dans une enveloppe : chacun est validé et livré indépendamment, dans l'ordre de déclaration, sans atomicité. Qui veut un tout-ou-rien fait un seul message à payload composite.

Examples et counterexamples

Ils prouvent le contrat. examples: { version: { révision: [payload, …] } } doivent valider ; counterexamples, entrées { reason, payload }, doivent être rejetés. test_engine.js les rejoue. Écrivez-les.

← Sources du chat Livraison →