Design & Développement web - Le topic des canards qui mangent des cookies

[moimadmax]

Justement git te permet de faire des branches pour essayer des trucs, et tu merges dans ta branche principale si ça te plaît ou pas.

- - - Mise à jour - - -

Et en plus si tu met sur git, on peut contribuer

Je sais que c'est possible, mais je ne sais pas comment faire. L'expérience me dit aussi que des fois avec Git, t'as vite fait de te mettre dans la meyrde. Du coup, un pas à la fois.
Je vais bientôt push sur github, il me reste au moins deux problème à gérer:
- Faire un truc dans le popup ou les options pour récupérer les favoris du localstorage
- remplacer ma fonction qui utilisait le DOM pour supprimer les caractère html (& et compagnie), mais il semblerait qu'il n'y a pas de fonction javascript pour ça.

[raaaahman]

Je trouve ce tutoriel très bien pour apprendre à se servir des branches Git.

J'ai en quelques sorte "réglé" le problème, mais j'ai honte.

Ca ne m'as pas l'air super robuste comme solution. Tu supposes que le process que tu attends va prendre - de 50ms et forcément aboutir, mais si ce n'est pas le cas, qu'est-ce qui se passe?

[Shurin]

J'ai viré le timeout de 50ms mais je n'arrive pas à reproduire ton erreur, même en killant le service-worker, c'est intriguant.

[moimadmax]

Ca ne m'as pas l'air super robuste comme solution. Tu supposes que le process que tu attends va prendre - de 50ms et forcément aboutir, mais si ce n'est pas le cas, qu'est-ce qui se passe?

C'est pour ça que j'ai un peu honte, mais ça fonctionne. En même temps, en théorie, d'après la doc (ma naïveté va en faire rire plus d'un) ça devrait fonctionner, à aucun moment il est question de faire un traitement spécifique sur la mécanique du message en cas de réveil du background. Pire, normalement si on tente d'envoyer un message dans un port déconnecté, ça doit lever une exception. Et ça ne lève rien du tout. Donc c'est connecté, mais le message ne passe pas.

J'ai viré le timeout de 50ms mais je n'arrive pas à reproduire ton erreur, même en killant le service-worker, c'est intriguant.

Pourtant j'ai testé sur un autre PC (on passe du core i3 2025 sous linux à un core i7 6700 sous win10) et ça fait pareil. c'est peut-être un peu lié à vivaldi. Sur mon vieux PC sous linux sous chromium le défaut était là aussi. Je n'ai pas chrome sur l'autre PC.

[raaaahman]

J'ai viré le timeout de 50ms mais je n'arrive pas à reproduire ton erreur, même en killant le service-worker, c'est intriguant.

J'ai viré le timer, et je ne vois pas le souci non plus.

C'est pour ça que j'ai un peu honte, mais ça fonctionne.

Ce n'est pas une question de honte ou de fierté, mais une solution comme ça, même si elle fonctionne les 50 fois où l'as testée, elle n'est pas garantie de fonctionner à chaque fois pour chacun de tes utilisateurs.

Par ailleurs, elle risque de compliquer la recherche des erreurs, et ne rends pas facile la collaboration, puisqu'on ne comprends pas ce que le script est supposé attendre

[Awake]

Un petit event pourrait faire l'affaire ? Je suis tombé là dessus sans garantir que ce serait la solution : https://developer.chrome.com/docs/ex...epts/messaging

[moimadmax]

J'ai viré le timer, et je ne vois pas le souci non plus.

C'est fou ça. t'as bien vérifié que le background était inactif ? C'est vraiment ça qui pose problème. Je vais tenter sur un troisième PC.

Ce n'est pas une question de honte ou de fierté, mais une solution comme ça, même si elle fonctionne les 50 fois où l'as testée, elle n'est pas garantie de fonctionner à chaque fois pour chacun de tes utilisateurs.
Par ailleurs, elle risque de compliquer la recherche des erreurs, et ne rends pas facile la collaboration, puisqu'on ne comprends pas ce que le script est supposé attendre

Je mettrai un petit commentaire explicite

Un petit event pourrait faire l'affaire ? Je suis tombé là dessus sans garantir que ce serait la solution : https://developer.chrome.com/docs/ex...epts/messaging

Même dans l'exemple sur cette page

var port = chrome.runtime.connect({name: "knockknock"});
port.postMessage({joke: "Knock knock"});
port.onMessage.addListener(function(msg) {
  if (msg.question === "Who's there?")
    port.postMessage({answer: "Madame"});
  else if (msg.question === "Madame who?")
    port.postMessage({answer: "Madame... Bovary"});
});

Il n'y a rien entre le connect et le postMessage.

[moimadmax]

Je viens de tester sur mon portable, un Ryzen 5 2500U sous windows 10 et Vivaldi, ça à fonctionné la première fois, mais pas les suivantes. Et sur le même PC sous Ubuntu, le bug est là aussi.

[moimadmax]

J'ai une question un peu à la con à propos des html entities pourquoi lorsque je passe le texte dans cette fonction :

function htmlDecode(input){
  var e = document.createElement('div');
  e.innerHTML = input;
  return e.childNodes.length === 0 ? "" : e.childNodes[0].nodeValue;
}

ces codes sont bien convertis (& = &)

Alors que lorsque je les inserts comme ça (le l.text) il ne sont pas convertis ?

    li = document.createElement('li');
    link = createElm('a', l.text, l.url)
    li.appendChild(link);

Est ce qu'il faut que je le passe dans ma fonction avant (link = createElm('a', htmlDecode(l.text), l.url)) ou en l'inserant d'une autre façon, cela changerait les HTML entities dans la foulée ?

PS: La fonction createElm :

function createElm(type, text, url){
  let ret = document.createElement(type);
  let txt = document.createTextNode(text);
  ret.appendChild(txt);
  if(url){
    ret.target = '_blank';
    ret.href = url;
    ret.title = text;
    ret.addEventListener('click', function(e) {
      e.preventDefault();
      chrome.tabs.create({url: e.currentTarget.href, active: false});
    }, false);
  }
  return ret;
}

[raaaahman]

Parce que lorsque tu assignes une chaîne à `innerHTML, cette chaîne est parsée et transformée en... HTML Voir la doc.

Pourquoi tu ne peux pas simplement écrire:

function createElm(type, text, url){
  let ret = document.createElement(type);
  ret.innerHTML = txt;
  if(url){
    ret.target = '_blank';
    ret.href = url;
    ret.title = text;
    ret.addEventListener('click', function(e) {
      e.preventDefault();
      chrome.tabs.create({url: e.currentTarget.href, active: false});
    }, false);
  }
  return ret;
}

Je mettrai un petit commentaire explicite

Explicite pour qui? Et ça ne résouds pas le souci de la prédictibilité du comportement de ton extension.

Je viens de tester sur mon portable, un Ryzen 5 2500U sous windows 10 et Vivaldi, ça à fonctionné la première fois, mais pas les suivantes. Et sur le même PC sous Ubuntu, le bug est là aussi.

On parle toujours de l'erreur expliquée dans ce message?

[moimadmax]

Parce que lorsque tu assignes une chaîne à `innerHTML, cette chaîne est parsée et transformée en... HTML Voir la doc.

Pourquoi tu ne peux pas simplement écrire:

function createElm(type, text, url){
  let ret = document.createElement(type);
  ret.innerHTML = txt;
  if(url){
    ret.target = '_blank';
    ret.href = url;
    ret.title = text;
    ret.addEventListener('click', function(e) {
      e.preventDefault();
      chrome.tabs.create({url: e.currentTarget.href, active: false});
    }, false);
  }
  return ret;
}

Explicite pour qui? Et ça ne résouds pas le souci de la prédictibilité du comportement de ton extension.



On parle toujours de l'erreur expliquée dans ce message?

Je vais tester pour le innerHTML, voir si ça ne crée pas d'autres soucis.

Je suis tout à fait d'accord avec toi sur le souci de prédictibilité, mais là, je n'ai pas de solution.
et c'était plutôt détaillé dans ce message: https://forum.canardpc.com/threads/7...1#post14408236

Mais pour reproduire, c'est simple, il faut supprimer le fameux timeout (popup.js:118) et charger l'extension.
Attendre qu'elle passe en inactive et ouvrir le popup.
Si ça reste sur chargement en cours ... c'est que ça bug.
Il se connecte bien au background (qui se réveil) mais il est un peu long au réveil, donc si on envoie dans la foulée le message reste coincé. Pour moi c'est plus un bug de chromium, car j'ai chercher dans la référence de l'API et à aucun cas il n'est question de précaution à prendre lorsque le background est en veille. D'ailleurs cette particularité est assez peu documenté finalement.

Puis l'horloge tourne, avant fin mai il faut que l'extension soit validée par le store. Donc pour bien, il faut que je la mette en validation cette semaine. Car des fois elle est refusée, et il faut faire des modifs.

[raaaahman]

Okay, en stoppant le service worker j'ai effectivement la même erreur. Par contre tu vois un message d'erreur quelque part toi?

Pour le calendrier, en Juin le Manifest V2 sera abandonné dans les versions développement et bêta uniquement, donc tu as encore un peu de temps.

Il se connecte bien au background (qui se réveil) mais il est un peu long au réveil, donc si on envoie dans la foulée le message reste coincé. Pour moi c'est plus un bug de chromium, car j'ai chercher dans la référence de l'API et à aucun cas il n'est question de précaution à prendre lorsque le background est en veille. D'ailleurs cette particularité est assez peu documenté finalement.

Attention avant de crier au bug: https://developer.chrome.com/docs/ex...-workers?hl=fr

Cela fonctionne avec une page d'arrière-plan persistante, car elle s'exécute en permanence et n'est jamais réinitialisée. Dans Manifest V3, le service worker est réinitialisé lorsque l'événement est envoyé. Cela signifie que lorsque l'événement se déclenche, les écouteurs ne sont pas enregistrés, car ils sont ajoutés de manière asynchrone, et l'événement sera manqué.

Dans ton cas, les écouteurs pour les messages 'PopupOpen' et 'PopupRefresh' sont enregistrés en rappel de l'écouteur sur chrome.runtime.onConnect, ce qui fait que le message 'PopupOpen' puisse être envoyé avant que chrome.runtime.onConnect aie appelé ta fonction de rappel, et donc avant que l'écouteur destiné à ce même message soit enregistré.

Donc ton timeout résouds le problème à condition que l'écouteur sur onConnect soit appelé en moins de 50 millisecondes, ce que tu ne peux pas garantir.

EDIT: J'ai lu dans la doc que c'est la méthode standard pour les connexions longue durée, le côté asynchrone de l'enregistrement de ton écouteur et de l'envoi du message associé est plutôt dû à la fonction loadData (dans les deux fichiers).

D'autant que ce message semble avoir pour but de retrouver des données qui sont stockées dans une variable globale (settings) du background, ce qui n'est plus dans la logique du Manifest V3: https://developer.chrome.com/docs/ex...persist-states

Conserver les états

Les service workers sont éphémères, ce qui signifie qu'ils sont susceptibles de démarrer, d'exécuter et d'arrêter plusieurs fois la session de navigateur d'un utilisateur. Cela signifie également que les données ne sont pas immédiatement disponibles dans les variables globales puisque le contexte précédent a été supprimé. Pour contourner ce problème, utilisez les API de stockage comme source de référence. Pour savoir comment procéder, consultez un exemple.

Mais bon, admettons que ça fasse l'affaire pour le moment, qu'est-ce qu'il te reste comme erreurs?

[01Azalea10]

Des Joueurs/euses de Code Wars ici ?

[moimadmax]

Okay, en stoppant le service worker j'ai effectivement la même erreur. Par contre tu vois un message d'erreur quelque part toi?

Non justement, pas d'erreur, ça fail en silence.

Pour le calendrier, en Juin le Manifest V2 sera abandonné dans les versions développement et bêta uniquement, donc tu as encore un peu de temps.

C'est plus détaillé dans le calendrier, dans les mails ou dans le tableau de bord dev, c'est indiqué que ça commence à shutdown en juin. Maintenant qu'elle est prête, je vais pas trop tarder quand même.

Attention avant de crier au bug: https://developer.chrome.com/docs/ex...-workers?hl=fr

Il sont gentil avec leur

Déplacez plutôt l'enregistrement de l'écouteur d'événements vers le niveau supérieur de votre script. Ainsi, Chrome pourra immédiatement trouver et appeler le gestionnaire de clics de votre action, même si votre extension n'a pas fini d'exécuter sa logique de démarrage.

Mais c'est pas toujours si simple. Mais j'ai essayé d'en tenir compte au maximum.
Et pour moi le bug vient plutôt du fait que le message ne passe pas, et que normalement si on tente d'envoyé un message sur un port non ouvert, ça lève une erreur.
Là j'ai ni l'un ni l'autre.

ADans ton cas, les écouteurs pour les messages 'PopupOpen' et 'PopupRefresh' sont enregistrés en rappel de l'écouteur sur chrome.runtime.onConnect, ce qui fait que le message 'PopupOpen' puisse être envoyé avant que chrome.runtime.onConnect aie appelé ta fonction de rappel, et donc avant que l'écouteur destiné à ce même message soit enregistré.

Donc ton timeout résouds le problème à condition que l'écouteur sur onConnect soit appelé en moins de 50 millisecondes, ce que tu ne peux pas garantir.

EDIT: J'ai lu dans la doc que c'est la méthode standard pour les connexions longue durée, le côté asynchrone de l'enregistrement de ton écouteur et de l'envoi du message associé est plutôt dû à la fonction loadData (dans les deux fichiers).

D'autant que ce message semble avoir pour but de retrouver des données qui sont stockées dans une variable globale (settings) du background, ce qui n'est plus dans la logique du Manifest V3: https://developer.chrome.com/docs/ex...persist-states

De memoire il récupère les infos du cache qui est dans session.cache, il y a peut-être quelques réglages venant de settings.*, mais ces 2 variables sont des objets qui viennent du stockage Chrome.storage.local pour settings et Chrome.storage.session pour session.
Je récupère leur contenu au lancement de l'extension.
Mettre chaque variable séparée dans le storage, est beaucoup trop lourd à gérer

Mais bon, admettons que ça fasse l'affaire pour le moment, qu'est-ce qu'il te reste comme erreurs?

Plus grand chose. Je la teste en local. J'ai trouvé encore un bug lié aux htmlEntities dans les liens, mais c'est réglé.
J'hésite à ajouter un truc pour récupérer les favoris.
Car je dois le mettre dans le popup ou les options, pour accéder au localstorage. Mais ça m’embête d'alourdir avec quelques chose qui ne servira qu'une fois. J'hésite encore.

[raaaahman]

Des Joueurs/euses de Code Wars ici ?

Nope. Un peu de CodinGame de temps en temps, mais pas depuis un moment.

Et pour moi le bug vient plutôt du fait que le message ne passe pas, et que normalement si on tente d'envoyé un message sur un port non ouvert, ça lève une erreur.
Là j'ai ni l'un ni l'autre.

Ben non, tu l'intercepte bien l'événement 'onConnect' dans ta vidéo. Sauf que tes écouteurs ne sont pas enregistrés immédiatement, comme le demande la documentation, mais en rappel de ta fonction loadData (qui enchaîne deux opérations asynchrones d'accès au stockage local et de session).

Pour respecter la nouvelle documentation, il faudrait que les écouteurs soient enregistrés de manière synchrone, et que tu attendes que leurs événements soient déclenchés pour aller retrouver des données dans le stockage local / de session:

// Connection d'un element externe
chrome.runtime.onConnect.addListener(function (port) {
  // loadDatas();

  if (port.name == "popup") {
    port.onDisconnect.addListener(function () {
      setTimeout(refreshCounter, 3 * 1000);
    });
    port.onMessage.addListener(function (request) {
      switch (request.action) {
        case "PopupOpen":
          ss.get(
            { session: { cache: "", nbThread: "", nbMsg: "" } },
            function (items) {
              const session = items.session;
              port.postMessage(
                extractLinks(session.cache, {
                  nbThread: session.nbThread,
                  nbMsg: session.nbMsg,
                })
              );
            }
          );

          break;
        case "PopupRefresh":
          refreshCounter(function () {
            ss.get(
              { session: { cache: "", nbThread: "", nbMsg: "" } },
              function (items) {
                const session = items.session;
                port.postMessage(
                  extractLinks(session.cache, {
                    nbThread: session.nbThread,
                    nbMsg: session.nbMsg,
                  })
                );
              }
            );
          });
          break;
      }
    });
  }
  if (port.name == "option") {
    port.onDisconnect.addListener(function () {
      init();
    });
  }
  if (port.name == "contentScript") {
    ls.get({ settings: { hideIgnoredPost: "" } }, function (items) {
      const settings = items.settings;
      port.postMessage({ hideIgnoredPost: settings.hideIgnoredPost });
    });
  }
});

De memoire il récupère les infos du cache qui est dans session.cache, il y a peut-être quelques réglages venant de settings.*, mais ces 2 variables sont des objets qui viennent du stockage Chrome.storage.local pour settings et Chrome.storage.session pour session.
Je récupère leur contenu au lancement de l'extension.

C'est bien ce que je dis. Autant c'était probablement pratique d'avoir les variables de session et de paramètres accessible dans l'espace global en V2, autant en V3 cette logique n'est plus possible, et essayer de recréer un comportement similaire n'est plus du tout pratique.

D'ailleurs, rien ne t'empêche d'accéder directement au stockage de session dans ton script de popup:

  // On demande les données du background.
  port = chrome.runtime.connect({ name: "popup" });
  // port.onMessage.addListener(function (msg) {
  //   dataReceived(msg);
  // });

  // port.postMessage({ action: "PopupOpen" });

  ss.get(
    { session: { cache: "", nbThread: 0, nbMsg: 0, readAllHash: "" } },
    function (items) {
      const session = items.session;
      const response = extractLinks(session.cache, {
        nbThread: session.nbThread,
        nbMsg: session.nbMsg,
      });
      dataReceived(response);
    }
  );

Il faudrait encore modifier les appels aux variables globales session et settings dans extractLinks, mais de toutes façon cela semble être la recommandation en V3.

Puis tu peux aussi directement écouter les changements du stockage plutôt que de faire des messages à deux sens:

  ss.onChanged.addListener(function (changes) {
    const session = changes.session.newValue;
    const response = extractLinks(session.cache, {
      nbThread: session.nbThread,
      nbMsg: session.nbMsg,
    });
    dataReceived(response);
  });

Ca simplifierait également la logique du service worker:

 port.onMessage.addListener(function (request) {
      switch (request.action) {
        case "PopupRefresh":
          refreshCounter(); // Stoque les nouvelles valeurs dans la session.
          break;
      }
    });

[Fastela]

Dîtes les canards, j'ai une petite question freelancing.

J'ai un contact qui est en train de me brancher sur une mission freelance sur un truc super intéressant, et il me propose de prendre une cut de 5% sur ma mission pour apport d'affaire. En sachant qu'il n'a pas juste donné mon tel au client, il va m'épauler sur le projet car je vais travailler avec lui en binôme.

Sur le papier ça me paraît pas déconnant (surtout que je galère de taf en ce moment, ça fait 4 mois que je cherche une mission, et pour le coup sur cette mission je facturerais un TJM le plus haut depuis le début de ma carrière), mais je n'ai jamais fait ça donc j'aimerais bien votre avis sur la question. Je sais que c'est une pratique assez courante, est-ce que le taux est OK ? Y'a des choses que je devrais prévoir ou discuter avec lui ?

[tenshu]

5% c'est pas cher du tout
De ce que je vois dans mon réseau c'est plutôt 10% voire plus

Si c'est du vrai accompagnement et que tu peux refacturer, je pense qu'il ne faut pas trop réfléchir.

[Orhin]

Le taux me parait très très correct en effet.

[tenshu]

Au niveau des trucs a discuter bah en fait il te faut un contrat.
Je te conseille de bien borner les choses par exemple dans le temps. J'avais un collègue qui bossait en freelance et il n'avait pas mis de délai au bout duquel la part de l'apporteur d'affaires expirait. Et lâcher 20% de sa facturation au bout de 3 ans ça fait mal.

[moimadmax]

Nope. Un peu de CodinGame de temps en temps, mais pas depuis un moment.



Ben non, tu l'intercepte bien l'événement 'onConnect' dans ta vidéo. Sauf que tes écouteurs ne sont pas enregistrés immédiatement, comme le demande la documentation, mais en rappel de ta fonction loadData (qui enchaîne deux opérations asynchrones d'accès au stockage local et de session).

Pour respecter la nouvelle documentation, il faudrait que les écouteurs soient enregistrés de manière synchrone, et que tu attendes que leurs événements soient déclenchés pour aller retrouver des données dans le stockage local / de session:

// Connection d'un element externe
chrome.runtime.onConnect.addListener(function (port) {
  // loadDatas();

  if (port.name == "popup") {
    port.onDisconnect.addListener(function () {
      setTimeout(refreshCounter, 3 * 1000);
    });
    port.onMessage.addListener(function (request) {
      switch (request.action) {
        case "PopupOpen":
          ss.get(
            { session: { cache: "", nbThread: "", nbMsg: "" } },
            function (items) {
              const session = items.session;
              port.postMessage(
                extractLinks(session.cache, {
                  nbThread: session.nbThread,
                  nbMsg: session.nbMsg,
                })
              );
            }
          );

          break;
        case "PopupRefresh":
          refreshCounter(function () {
            ss.get(
              { session: { cache: "", nbThread: "", nbMsg: "" } },
              function (items) {
                const session = items.session;
                port.postMessage(
                  extractLinks(session.cache, {
                    nbThread: session.nbThread,
                    nbMsg: session.nbMsg,
                  })
                );
              }
            );
          });
          break;
      }
    });
  }
  if (port.name == "option") {
    port.onDisconnect.addListener(function () {
      init();
    });
  }
  if (port.name == "contentScript") {
    ls.get({ settings: { hideIgnoredPost: "" } }, function (items) {
      const settings = items.settings;
      port.postMessage({ hideIgnoredPost: settings.hideIgnoredPost });
    });
  }
});

C'est bien ce que je dis. Autant c'était probablement pratique d'avoir les variables de session et de paramètres accessible dans l'espace global en V2, autant en V3 cette logique n'est plus possible, et essayer de recréer un comportement similaire n'est plus du tout pratique.

D'ailleurs, rien ne t'empêche d'accéder directement au stockage de session dans ton script de popup:

  // On demande les données du background.
  port = chrome.runtime.connect({ name: "popup" });
  // port.onMessage.addListener(function (msg) {
  //   dataReceived(msg);
  // });

  // port.postMessage({ action: "PopupOpen" });

  ss.get(
    { session: { cache: "", nbThread: 0, nbMsg: 0, readAllHash: "" } },
    function (items) {
      const session = items.session;
      const response = extractLinks(session.cache, {
        nbThread: session.nbThread,
        nbMsg: session.nbMsg,
      });
      dataReceived(response);
    }
  );

Il faudrait encore modifier les appels aux variables globales session et settings dans extractLinks, mais de toutes façon cela semble être la recommandation en V3.

Puis tu peux aussi directement écouter les changements du stockage plutôt que de faire des messages à deux sens:

  ss.onChanged.addListener(function (changes) {
    const session = changes.session.newValue;
    const response = extractLinks(session.cache, {
      nbThread: session.nbThread,
      nbMsg: session.nbMsg,
    });
    dataReceived(response);
  });

Ca simplifierait également la logique du service worker:

 port.onMessage.addListener(function (request) {
      switch (request.action) {
        case "PopupRefresh":
          refreshCounter(); // Stoque les nouvelles valeurs dans la session.
          break;
      }
    });

C'est lié au fait que je l'ai adaptée, si j'avais du tout réécrire, j'aurais peut-être fait différemment. Dans tes exemples c'est plus en phase avec les guidelines de Google, mais lorsque le background n'a pas été killé, c'est je pense plus rapide de le récupérer de la mémoire que d'aller le chercher dans le stockage. Puis même au niveau du code, c'est plus lourd quand même de faire un appel asynchrone qu'une simple consultation de variable. Honnêtement si j'avais su dès le début de ce chantier que tout été killé régulièrement, et les soucis que j'ai eu par la suite, je serais peut-être parti sur cette voie, mais là, maintenant que ça fonctionne j'ai la flemme de tout re-péter. Peut-être pour la prochaine révision lorsque PresseNonStop va mettre ce forum à la retraite.

Dans tous les cas, je te remercie pour ton aide. Et aussi les autres de ce topic, ça fait du bien de se sentir soutenu.

[Awake]

Si j'avais eu plus de temps et de connaissances, j'aurais volontiers aidé plus, ton extension est cool.

Sinon je cherchais un moyen de push des data depuis un serveur vers une page, sans passer par les websockets, et je découvre les Server Sent Events (SSE). J'ai fait un proto sur node + express, en utilisant 0 libraries supplémentaires côté serveur comme front, ça marche incroyablement bien. C'est supporté par tous les navigateurs en plus !

Y'a que moi qui suis passé à côté ? Vous connaissiez ? C'est incroyable !

[Dross]

J'ai déjà utilisé une fois de mémoire.

Mais honnêtement aujourd'hui websocket est super bien supporté et perso je préfère utiliser des encapsulations comme SignalR.

[Awake]

Pour le coup Websocket je connais bien et c'est tout de même plus complexe et fragile. Les décos sont plus fréquentes et moins faciles à gérer. J'espère que SSE sera plus stable, il se reco tout seul nativement, et après tout c'est juste un call http, quoi de plus supporté

[Dross]

C'est pour ça que les encapsulations comme SignalR sont utiles.

[raaaahman]

Dans tous les cas, je te remercie pour ton aide. Et aussi les autres de ce topic, ça fait du bien de se sentir soutenu.

Merci à toi de faire une extension pour faciliter la vie des canards.

Sinon je cherchais un moyen de push des data depuis un serveur vers une page, sans passer par les websockets, et je découvre les Server Sent Events (SSE). J'ai fait un proto sur node + express, en utilisant 0 libraries supplémentaires côté serveur comme front, ça marche incroyablement bien. C'est supporté par tous les navigateurs en plus !

Y'a que moi qui suis passé à côté ? Vous connaissiez ? C'est incroyable !

Je n'en avais jamais entendu parlé! Par contre j'ai un peu du mal à imaginer des utilisations où tu as besoin d'une connexion en temps réel à un seul sens...

[Awake]

Une utilisation tout simple :
Tu as des données comme des recaps d'actualités qui sont balancées sur un RabbitMQ ou un kafka par exemple
Ton serveur écoute ces events, et quand il en reçoit un, met à jour le SSE avec la nouvelle actualité
Côté front on se connecte au endpoint SSE du server, et bim, on reçoit les actualités en temps réel

[GrandFather]

Pour un projet (intranet) de notifications en temps réel envoyées par un backend Symfony j'avais utilisé Mercure, ça marche super bien.

[raaaahman]

Mouais, chuis pas super fan d'être bombardé de notifs en permanence, mais peut-être que ce sera utile pour d'autres personnes.

On en a beaucoup des applis qui ne sont là que pour relayer les événements d'autres sites? Parce qu'en terme d'éco-compatibilité, ça m'a l'air de ne pas être optimal...

[GrandFather]

Y'a des cas d'utilisations où c'est bien plus efficace qu'un mail ou tout autre medium de communication, tant écologiquement que fonctionnellement. Dans mon cas, les notifications servent à alerter en temps réel les utilisateurs d'incidents de production survenus sur les outils métiers qu'ils utilisent.

[tenshu]

Y'a que moi qui suis passé à côté ? Vous connaissiez ? C'est incroyable !

Dans ma boîte on utilise Mercure pour envoyer des notifications au front-end. Ça marche parfaitement bien.

https://mercure.rocks/