4.5 et Core JS : CustomEvent

Salon des Développeurs Core V4 (dev)
1

Bonsoir,

Je viens de terminer de migrer mes plugins TTSCast et TVRemote en vanilla JS (les deux sur la branche béta).

Au delà du temps que cela prend :open_mouth: (et que j’aime toujours autant le Javascript :rofl: ), globalement cela fonctionne bien à l’arrivée, et même avec des performances un peu meilleures (d’après la console dev de Chrome en tout cas) sur le traitement et le chargement des éléments des pages.

Globalement, j’ai pu tester la migration de « click » sur des boutons, d’ouverture de pages sur un nouvel onglet au click sur un bouton, d’envoi de fichier (téléchargement d’un fichier qui s’ajoute à un répertoire du plugin), lancement d’Ajax en tout genre, construction de la table de commandes, etc…

Mais je n’ai pas pu éradiquer le jQuery à 100% :thinking:, il reste une toute petite fonction dans le code, et c’est l’objet de ce message :slight_smile: :

  • Les « CustomEvents »

J’utilise des customevents sur la page de ces deux plugins, notamment pour gérer des évènements comme l’envoi et le retour de code d’appairage, ou le lancement et l’arrêt d’un scan automatique d’équipements.

Or, lorsque j’implémente les eventListener('ttscast::scanState, ...) par exemple, en vanilla JS, ils ne réagissent pas dans Jeedom lorsque je clique sur le bouton « Scan ».

Pour que cela fonctionne, j’ai dû implémenter un bridge jQuery vers CustomEvents :

Et là cela fonctionne comme attendu.

PS : Alors oui, en désactivant le jQuery complètement de Jeedom via l’option du panneau de configuration, cela fonctionne, mais là l’idée était de profiter, dans cette période de transition, du Vanilla JS pour les plugins qui le supportent sans pour autant forcer l’utilisateur à désactiver le jQuery… :open_mouth:

Après un bon moment à chercher, j’ai regardé dans le code du core de Jeedom, et j’ai fini par trouver que cela pourrait venir de ce bout de code :

Fichier core/js/jeedom.class.js (lignes 84 à 94) :

Et je me demandais pourquoi avoir filtrer pour n’autoriser le dispatchEvent « natif » que sur certains types de customevents et ne pas autoriser tous les customevents à être dispatchés en vanilla JS et laisser le jQuery comme sorte de fallback (les deux tourneraient donc) ?

par exemple via ce code modifié :

const eventName = data.result[i].name
if (eventName) {
  const eventDetail = isset(data.result[i].option) ? data.result[i].option : undefined
  document.body.dispatchEvent(new CustomEvent(eventName, { detail: eventDetail }))
  if (typeof jQuery === 'function') {
    $('body').trigger(eventName, eventDetail)
  }
}

Suivant vos réponses et retour sur le sujet, je pourrai proposer ce bout de code en PR sur la branche 4.5.2

Bonne soirée,
TiTidom.

3

Coucou,

Désolé je suis pas devant le Pc, mais c’est un soucis que j’avais deja constaté, et que javais remonté il me semble.

De memoire, il me semble que c’est Kiboost qui m’avais confirmer que c’était pas possible d’utiliser un body.dispatch car lors du chargement du plugin.js, le core a deja chargé le body.

Pour contourner, il me semble qu’il faut monter un event.js et le déclarer dans le fichier info.json

Désolé ce sont que des supposition, je suis pas devant mon pc pour confirmer.

Edit : Il était temps que 2025 se termine :rofl:, j’avais rien compris de ton analyse :crazy_face:

1 « J'aime »
4

Hello,

J’en profite pour souhaiter une bonne et heureuse année 2026.

J’ai regardé un peu plus en profondeur le code, devant un pc c’est plus pratique :wink:

Effectivement, tes remarques sont bonnes, et j’ai peut-être un début d’explication :

Car a ce jour, seul le core est full js, donc je pense que l’équipe voulait garder le compatibilité avec les plugins qui a ce jour ne sont pas encore obligé de basculler en full js.

Moi je pense qu’il faudrait tout simplement lancer le dispatchEvent dans le else, et en parallèle si jQuery est activé, lancé le trigger :

        if (isset(data.result[i].option)) {
          if (['scenario::update', 'ui::update', 'jeedom::gotoplan', 'jeedom::alert', 'jeedom::alertPopup', 'jeedom::coloredIcons', 'message::refreshMessageNumber', 'update::refreshUpdateNumber', 'notify', 'checkThemechange', 'changeTheme'].includes(data.result[i].name)) {
            document.body.dispatchEvent(new CustomEvent(data.result[i].name, { detail: data.result[i].option }))
          } else {
            document.body.dispatchEvent(new CustomEvent(data.result[i].name, { detail: data.result[i].option }))
            if (typeof jQuery === 'function') {
              $('body').trigger(data.result[i].name, data.result[i].option)
            }
          }
        } else {
          document.body.dispatchEvent(new CustomEvent(data.result[i].name))
        }

Voir même encore plus simple :

        if (isset(data.result[i].option)) {
          document.body.dispatchEvent(new CustomEvent(data.result[i].name, { detail: data.result[i].option }))
          if (typeof jQuery === 'function') {
            $('body').trigger(data.result[i].name, data.result[i].option)
          }
        } else {
          document.body.dispatchEvent(new CustomEvent(data.result[i].name))
        }

Ce qui revient a ton code modifié :grin: qui je pense est très bien adapté.

1 « J'aime »
5

Hello,

J’en profite également pour souhaiter à mon tour une bonne et heureuse année 2026 :slight_smile:

Merci @Phpvarious pour ce retour, qui va dans le même sens que ma proposition, et en général c’est bon signe quand cela converge :stuck_out_tongue:

Suite à ton premier message (tu as beau l’avoir barré, j’ai cherché partout sur le forum si je retrouvais ces échanges loooll), cela m’a fait réfléchir sur ces events, et j’en ai profité pour améliorer leur gestion dans mes plugins, en protégeant le chargement de ces events, pour éviter qu’ils ne se multiplient au fil des navigations sur les pages (protection contre le double chargement), alors merci de m’y avoir fait penser :clap:

Je vais regarder pour proposer un PR en ce sens, même si j’avoue que je suis un peu perdu sur la branche à choisir :stuck_out_tongue: Par exemple, avec la version 4.5.2 qui est sorti en urgence (et tant mieux, c’est une très bonne chose, et chapeau pour la réactivité), j’imagine que la branche 4.5.2 va devoir être renommée 4.5.3 ? Bref, quelle branche source choisir ? :confused:

Bonne journée,
TiTidom.

6

Oui je pense que Salvialf renommera la branch en 4.5.3 en prenant en compte le commit de Loic.
Donc je pense qu’il faut PR sur la 4.5.2 en attendant.

1 « J'aime »
7

Bonsoir,

Le PR est fait :

Bonne soirée,
TiTidom.