Comment contourner DOMContentLoaded pour la navigation ?

Nous avons une fonction js qui s’exécute sur DOMContentLoaded, document.addEventListener(“DOMContentLoaded”, OURFUNCTION).

Cela fonctionne bien lorsque vous actualisez le navigateur, mais ne s’affiche jamais lorsque vous naviguez sur le site. Je suppose que c’est parce que Discourse ne charge le DOM qu’une seule fois, puis le reste est géré avec la navigation côté client, comme une SPA. Je me demande donc comment exécuter la fonction lors d’un changement de navigation dans Discourse lui-même ? Il y avait auparavant des moyens faciles de le faire via l’API des plugins, mais ces API sont obsolètes et je ne les vois plus utilisées dans aucun composant. Existe-t-il un moyen simple de le faire encore ? Ou devons-nous créer un composant entier juste pour exécuter du JavaScript lors d’un changement de navigation ? Merci.

Salut,

Si vous cherchez un événement appelé lors du chargement de la page, il y a api.onPageChange.

api.onPageChange((url, title) => {
   console.log('la page a changé pour : ' + url + ' et le titre ' + title);
});

Si vous cherchez autre chose, pouvez-vous préciser ce que vous voulez accomplir ? Nous pourrions vous donner une réponse plus précise.

Par ailleurs, vous avez une tonne de documentation qui pourrait vous être utile : Developer Guides - Discourse Meta.

3 « J'aime »

Hmmm… Je ne suis pas sûr que cela garantisse que le contenu du DOM soit chargé, je crois que cela se déclenche lors du changement de route, ce qui est beaucoup plus tôt.

Vous devriez envisager de joindre un composant à un Plugin Outlet et de déclencher le modificateur didInsert si le chargement du DOM est important.

Si seul le changement de route est important, alors oui, onPageChange devrait suffire :+1:

1 « J'aime »

Tu as peut-être raison ! :thinking:

onPageChange est appelé lors de la prochaine boucle d’événements, donc je pense qu’il sera toujours appelé après DOMContentLoaded dans la plupart des situations, mais je ne peux pas garantir que ce soit le cas.

Je vois des utilisations qui s’appuient sur onPageChange et font directement des choses avec des éléments DOM. D’où est déclenché l’événement routeDidChange d’ailleurs (EDIT : il vient d’ember : RouterService | 6.7.0 | Ember API Documentation ) ?

Je suis d’accord avec le modificateur didInsert, vraiment ingénieux !

1 « J'aime »

Merci. J’ai lu la documentation en détail et, conformément à mes commentaires et à un suivi d’un membre de Discourse, l’API des plugins est obsolète et sera bientôt dépréciée. Donc, bien que votre code puisse fonctionner maintenant, il cessera bientôt de fonctionner, je pense lors de futures mises à jour. C’est pourquoi je cherche une meilleure solution. Il semble excessif de créer un composant Glimmer pour cela, j’espérais donc qu’il existait un autre événement que nous pourrions utiliser.

Je ne crois pas que ce soit exact.

a été mis à jour la semaine dernière.

Ce qui est déprécié, ce sont :

  • L’API des widgets
  • Les modèles bruts
  • La substitution générale des modèles
3 « J'aime »

Merci pour ces précisions ! Il s’agit donc uniquement de l’API des widgets. D’accord, je vais d’abord essayer les suggestions d’API ci-dessus.

3 « J'aime »

C’est une sorte de bénédiction :sweat_smile:, Glimmer est beaucoup plus convivial pour les développeurs

2 « J'aime »

Soit dit en passant, nous l’avons testé avec api.OnPageChange et cela fonctionne bien. Nous n’avons pas encore rencontré de cas où le contenu du DOM n’était pas disponible lors de l’appel à OnPageChange, il semble donc qu’il soit déclenché après DomContentLoaded. Mais, je ne peux pas être sûr à 100 %. Merci pour votre aide à ce sujet.

3 « J'aime »

Bien. Soyez juste conscient que le timing n’est pas garanti. Mais je suis content que cela fonctionne pour votre cas d’utilisation !

1 « J'aime »

Pouvez-vous mieux expliquer ce que cela signifie ? Qu’est-ce que le modificateur didInsert ? Je déclenche sur le decorateCookedElement. Merci.

1 « J'aime »
1 « J'aime »

Le doc est la voie à suivre comme l’a souligné Robert ; vous pouvez également voir une tonne d’exemples sur le dépôt : Code search results · GitHub

1 « J'aime »

Ah, d’accord, c’est donc une fonctionnalité d’Ember et pas lié à Discourse ? La seule partie du code qui est vraiment liée à “Discourse” serait le pluginoutlet ?

1 « J'aime »

Oui, cela fait partie de la norme Glimmer

Les pluginOutlets sont juste des Components spéciaux conçus pour monter d’autres Components :

2 « J'aime »