L'objet standard et les règles de deps
Les cinq règles de deps
- Tout ce qui n'est ni le broker ni le nom d'instance arrive par deps, à la construction. Jamais de
process.env, d'import de configuration, de singleton. Ce qu'un composant ne reçoit pas, il ne l'a pas. - deps est opaque au framework, à une clé près : support, normalisée au constructeur, nettoyée par
destroy().depsn'est pas un second catalogue. - Un handle ne voyage jamais en message : une ressource se passe au constructeur.
- La propriété reste au point de composition :
destroy()ne ferme pas ce qu'il n'a pas ouvert. Seule exception : un canal ferme son transport sur violation de protocole. - On passe la ressource ouverte, pas son URL : un pool, pas une chaîne de connexion ; un socket, pas une adresse.
config.js et .env peuvent exister ; seuls server.js et index.html ont le droit de les importer.
Supports
Un composant dont l'interface vit à deux endroits reçoit une carte : { support: { liste: node, saisie: node } }. Il peint dans this.supports.liste et this.supports.saisie ; this.support vaut undefined, et c'est correct. Sans cette possibilité, il faudrait découper par la géométrie de l'écran là où le framework demande de découper par fonction.
Cycle de vie
- Un objet non désinscrit reste abonné.
a = nullne détruit rien : abonné fantôme et fuite mémoire. Toute destruction passe pardestroy(). - La désinscription est immédiate.
- L'identité de l'objet est contrôlée à l'émission comme à la désinscription : un homonyme ne peut ni émettre ni désinscrire à la place d'un autre.
ERROR (broker): message_demande published by ecran_fil without emitter registration — dropped
ERROR (broker): message_poste: unregister by ecran_fil refused — the registration belongs to another object (homonym)
Composants uniques
Le cas normal est une instance par classe. Ne faites jamais transiter un nom d'instance dans un payload. Pour corréler un aller-retour : un ref de message (UUID). Pour atteindre un client : la clé d'enveloppe id.