IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

TiranusKBX

[Actualité] L'API EventSource, ce que c'est et comment l'utiliser

Note : 2 votes pour une moyenne de 3,00.
par , 03/04/2015 à 10h05 (1311 Affichages)
L'API EventSource introduite dans les spécificités accompagnant le HTML5 sert à récupérer et traiter des événements/messages renvoyés par un serveur sur une connexion HTTP continue.
Les données sont retournées au format "text/event-stream".
Une source d’événement peut être déclarée de la façon suivante :
Code Javascript : Sélectionner tout - Visualiser dans une fenêtre à part
var sourceEvents = new EventSource("http://urlsite/events.php");

Il y a deux utilisations possibles de cette connexion :
  1. Remontée de message uniquement ;
  2. Remontée d’événement avec ou sans données.

Dans tous les cas, les "messages" doivent être séparés par deux mises à la ligne servant à distinguer les blocs, dans le cas contraire cela signifie que la mise à la ligne fait partie des données.

Exemple de données message uniquement :
data: This is the first message.

data: This is the second message, it
data: has two lines.

data: This is the third message.
Dans ce cas de figure, on utilisera le code suivant :
Code Javascript : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
sourceEvents.onmessage = function (event) {
    console.log(event.data);
    //traitement à effectuer
};

Voici maintenant un cas avec des événements :
event: add
data: 73857293

event: remove
data: 2153

event: add
data: 113411
Dans ce cas de figure, on utilisera le code suivant :
Code Javascript : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
sourceEvents.addEventListener("change", function (event) {
    console.log(event.data);
    //traitement à effectuer
}, false);

Dans le cas plus que probable où vous auriez une erreur, vous pouvez créer votre propre gestionnaire :

Code Javascript : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
sourceEvents.onerror = function (e) {
    console.log(e);
    if (sourceEvents.readyState == 2) {
        // traitement en cas de déconnexion définitive
        }
    if (sourceEvents.readyState == 0) {
        //traitement dans le cas d'une déconnexion temporaire
    }
};

/!\ En cas de déconnexion, celle-ci est relancée automatiquement au bout de 3 secondes par le navigateur.

Sources

Envoyer le billet « L'API EventSource, ce que c'est et comment l'utiliser » dans le blog Viadeo Envoyer le billet « L'API EventSource, ce que c'est et comment l'utiliser » dans le blog Twitter Envoyer le billet « L'API EventSource, ce que c'est et comment l'utiliser » dans le blog Google Envoyer le billet « L'API EventSource, ce que c'est et comment l'utiliser » dans le blog Facebook Envoyer le billet « L'API EventSource, ce que c'est et comment l'utiliser » dans le blog Digg Envoyer le billet « L'API EventSource, ce que c'est et comment l'utiliser » dans le blog Delicious Envoyer le billet « L'API EventSource, ce que c'est et comment l'utiliser » dans le blog MySpace Envoyer le billet « L'API EventSource, ce que c'est et comment l'utiliser » dans le blog Yahoo

Mis à jour 03/04/2015 à 22h33 par f-leb

Catégories
Javascript , Développement Web

Commentaires

  1. Avatar de xulien
    • |
    • permalink
    Si je comprends bien, c'est une sorte de XMLHttpRequest revisité?
  2. Avatar de TiranusKBX
    • |
    • permalink
    Citation Envoyé par xulien
    Si je comprends bien, c'est une sorte de XMLHttpRequest revisité?
    Il y a une grosse différence entre les 2 dans le cas du XMLHttpRequest c'est une requete et dans le cas de L'API EventSource une connexion continue.

    Pour le XMLHttpRequest vous posez une question et l'on vous répond sur une connexion
    pour L'API EventSource on dit salut et le serveur vous donne des directives

    De ce fait dire que c'est du XMLHttpRequest revisité ne tient pas, le comportement est totalement différent
  3. Avatar de xulien
    • |
    • permalink
    Citation Envoyé par TiranusKBX
    Il y a une grosse différence entre les 2 dans le cas du XMLHttpRequest c'est une requete et dans le cas de L'API EventSource une connexion continue.

    Pour le XMLHttpRequest vous posez une question et l'on vous répond sur une connexion
    pour L'API EventSource on dit salut et le serveur vous donne des directives

    De ce fait dire que c'est du XMLHttpRequest revisité ne tient pas, le comportement est totalement différent
    Effectivement, mais ce n'est pas évident à la lecture de ton article (je ne te jette pas de pierres, je fais juste un retour d'expérience ), car j'ai tout d'abord pensé aux websockets, pour finalement m’apercevoir qu'il ne s'agissait pas d'un protocole en soit, et il m'a fallut fouiller un peu et voir https://developer.mozilla.org/en-US/...er-sent_events pour y voir un embryon de finalité qui est de faire du push, à pas trop chère. Par contre, si j'ai bien compris, contrairement aux websockets, ce n'est pas bidirectionnel.


    edit: en fait, ton intro "sert à récupérer et traiter des événements/messages renvoyés par un serveur sur une connexion HTTP continue.
    Les données sont retournées au format "text/event-stream"." était juste, mais un peu courte, pour d'un coup d'oeil en comprendre les tenants et aboutissant.
  4. Avatar de TiranusKBX
    • |
    • permalink
    Citation Envoyé par xulien
    edit: en fait, ton intro "sert à récupérer et traiter des événements/messages renvoyés par un serveur sur une connexion HTTP continue.
    Les données sont retournées au format "text/event-stream"." était juste, mais un peu courte, pour d'un coup d'oeil en comprendre les tenants et aboutissant.
    c'est que donner des cours ce n'est pas ma spécialité et pour moi les réponses courtes sont les meilleures, ça évite de s'embrouiller
    Mis à jour 06/04/2015 à 23h33 par TiranusKBX
  5. Avatar de xulien
    • |
    • permalink
    Citation Envoyé par TiranusKBX
    c'est que donner des cours ce n'est pas ma spécialité et pour moi les réponses courtes sont les meilleures, ça évite de s'embrouiller
    Ce n'est pas ma spécialité non plus, et n'y vois surtout pas une critique acerbe! Je ne connaissais pas cette api, le sujet m'intéresse, mais à la première lecture, je n'ai pas forcement capté de quoi il s'agissait. Et je pense que cela gagnerais en clarté avec une introduction sur le contexte d'utilisation. Surtout, continu