Sign inGet started

Exclure des destinataires d'un événement

Si un client applique une modification de manière optimiste avant que votre serveur ne la publie, la réception du même événement peut appliquer la modification deux fois. Cela peut provoquer un scintillement ou un élément en double.
Transmettez l'identifiant de connexion du client agissant pour distribuer l'événement à toutes les autres connexions abonnées.
await bird.realtime.publish(appId, {
  event: "message.created",
  channels: ["presence-room-1"],
  data: { body: "hello" },
  exclude_connection_id: "26896.319537",
});

Obtenir l'identifiant de connexion

Le client lit son identifiant de connexion et l'envoie avec la requête qui déclenche la modification :
const bird = new BirdRealtime({ appKey: "your-app-key", region: "us1" });

await fetch("/messages", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({
    body: "hello",
    connection_id: bird.connection.connectionId,
  }),
});
L'identifiant est null tant que la connexion n'est pas établie et change après une reconnexion. Lisez bird.connection.connectionId dans le navigateur ou bird.connectionId en Swift et Kotlin au moment de la requête.
Transmettez la valeur à exclude_connection_id après l'avoir validée en tant que donnée de requête non fiable. Ce champ peut supprimer la distribution vers une connexion, mais ne peut pas accorder l'accès à un événement.

Comportement de la connexion exclue

Seule la connexion désignée est exclue. Les autres onglets de la même personne utilisent des connexions distinctes et reçoivent toujours l'événement.
Exclure un identifiant de connexion qui n'est pas abonné, ou qui n'existe plus, ne produit pas d'erreur. La publication est distribuée normalement à tous les autres.

Quand ne pas exclure

Utilisez l'exclusion pour les interfaces optimistes. Si le client attend l'événement avant d'appliquer une modification, ne l'excluez pas. Sinon, l'onglet à l'origine de l'action reste obsolète.

Étapes suivantes