PluginOutlet manquant pour le composant second-factor.gjs et pour second-factor-add-totp.gjs

Salut
J’ai récemment commencé à travailler avec Discourse et, d’après mon expérience d’une semaine, je peux certainement dire que le niveau d’entrée est assez élevé pour un développeur qui a réellement besoin de modifier les éléments de base. Cela est dû au manque de documentation/informations réelles, surtout si nous parlons des nouvelles options les plus récentes, car je ne trouve que des choses qui ne fonctionnent plus pour la version 3.6.0 plutôt que la nouvelle approche, et même si j’en trouve, le niveau de détail est faible, pas d’exemples concrets ou d’explications plus détaillées sur la façon d’utiliser les choses.
Néanmoins, je dois modifier le composant second-factor-add-totp.gjs et je n’ai pas pu le faire car il n’y a aucune information sur la façon de le faire correctement dans mon thème personnalisé.
J’ai trouvé qu’il existe quelque chose appelé PluginOutlet qui est conçu pour fonctionner comme un crochet que vous pouvez utiliser pour injecter votre code personnalisé ou même modifier la sortie si l’élément est encapsulé dans PluginOutlet (pas sûr, il y a quelque chose comme api.renderInOutlet, mais je n’ai trouvé aucune information normale sur la façon de l’utiliser). En regardant ces composants Ember, je ne vois pas de PluginOutlet qui pourrait éventuellement aider à faire au moins quelques manipulations avec la structure en utilisant au moins du JS pur.

Pouvez-vous clarifier si c’est quelque chose qui peut être ajouté là et si je peux l’utiliser pour modifier la structure de la fenêtre modale ou au moins utiliser du JS pur pour déplacer certains éléments à leur place.
Aussi, peut-être que je n’ai pas trouvé, mais existe-t-il une documentation avec des exemples pour les nouvelles approches ?

1 « J'aime »

Pouvez-vous partager plus de détails sur votre objectif final afin que nous puissions vous donner de meilleurs conseils ?

1 « J'aime »

Bien sûr.
Donc, selon la version « modifiée » que j’ai, je dois mettre à jour un peu la conception pour la modale MFA (lorsque l’utilisateur doit configurer une application d’authentification pour la MFA).
Par mise à jour, j’entends par exemple déplacer le code QR dans la structure HTML, pour être plus précis, le texte du site « js.user.second_factor.enable_description », le code QR devrait se trouver quelque part entre le nouveau texte fourni (balisage HTML).
Un autre exemple est de s’assurer que « Entrer manuellement » affiche plutôt le code réel qui peut être copié en cliquant dessus (manuellement via un déclencheur JS pour qu’il apparaisse et le déplacer simplement).

Tout cela peut être réalisé à l’aide de manipulations JS régulières, sans reconstruction réelle de la structure du composant d’origine, mais le principal défi pour moi est de trouver un endroit où ce JS peut être placé afin qu’il soit déclenché lorsque la modale est ouverte, ce que je n’ai pas encore réussi à trouver.

Clarification supplémentaire : j’utilise un thème personnalisé qui est stocké à l’aide de l’option GIT.

Faites-moi savoir si quelque chose n’est pas clair.

Salut @Falco , as-tu des suggestions ?

Salut @Yan_Rudenko, les meilleures documentations pour commencer sont probablement ce tutoriel :

Comme vous l’avez mentionné, les Plugin Outlets sont le meilleur moyen de personnaliser l’interface utilisateur. Mais ils ne sont pas disponibles partout. Seules certaines parties de l’interface utilisateur sont conçues pour être personnalisées.

Manipuler le DOM avec du JS classique provoquera des erreurs, car notre framework de rendu perdra le contrôle des éléments qu’il a rendus à l’écran. Il est préférable de s’en tenir aux plugin outlets pris en charge et aux autres API JS de Discourse (également abordées dans le tutoriel).

3 « J'aime »

Salut @david, merci pour le lien du tutoriel, mais je l’ai déjà consulté et je n’y ai pas trouvé les réponses que je cherchais. Les exemples eux-mêmes sont basiques et ne couvrent pas, par exemple, comment obtenir une catégorie spécifique (au lieu de faire un appel ajax) ou comment utiliser l’API Discourse dans le code (mentionné sur https://docs.discourse.org/), qui est présente d’après ce que je sais et vois. C’est pourquoi j’ai écrit ici afin d’obtenir plus de détails de la part des personnes qui travaillent avec Discourse au quotidien et qui connaissent beaucoup de choses qui ne sont pas présentes dans la documentation.

Je comprends tout à fait que l’utilisation de JS pur puisse causer des problèmes, mais c’est la seule chose à laquelle j’ai pensé pour l’instant. Peut-être qu’à l’avenir, je serai en mesure de modifier certaines choses de manière plus appropriée s’il y en a.

Donc, si je comprends bien, dans la version actuelle de Discourse que j’utilise, qui est 3.6.0.beta2-latest, les changements que j’ai mentionnés ne pourront pas être réalisés avec les outils intégrés de Discourse ? En raison de l’absence de PluginOutlets dans ces composants ?

L’équipe de développement envisage-t-elle d’ajouter cela aux composants mentionnés dans les futures versions, car je suppose qu’il n’y a pas de problèmes techniques, mais une question de décision de la part des personnes qui travaillent sur ce sujet ?

Merci.

Oui ! Vous êtes invité à créer une PR pour le cœur de Discourse qui introduit de nouveaux points de sortie.

Je ne peux pas promettre qu’elle sera acceptée immédiatement. Mais une fois que nous aurons un point de départ, il sera plus facile de poursuivre la discussion.

2 « J'aime »

@david, merci pour la proposition, je l’examinerai lorsque j’aurai le temps de le faire, mais vous devez comprendre que pour une personne qui vient d’arriver sur Discourse, cela peut prendre du temps, car je dois déterminer comment en préparer un avec les bonnes modifications + comme vous l’avez mentionné, l’étape d’approbation + le temps avant qu’il n’entre dans la prochaine version elle-même.
J’espérais que l’équipe de développement, beaucoup plus qualifiée, pourrait le préparer en 1 heure s’il s’agissait seulement d’ajouter un wrapper PluginOutlet et quelques éléments dans les composants à différents endroits (je pourrais me tromper), ce qui réduirait le temps nécessaire pour l’intégrer dans la nouvelle version.

Néanmoins, comme je l’ai mentionné ci-dessus, j’examinerai votre proposition.

Cependant, je n’ai toujours pas reçu de réponse concernant ma question, à savoir s’il est possible de faire les choses que j’ai mentionnées dans la version actuelle de Discourse ou si les modifications que j’ai mentionnées doivent d’abord être ajoutées/contribuées (ajout du PluginOutlet dans ces composants) ?

La raison pour laquelle je pose cette question est que j’ai un périmètre de travail qui doit être effectué, mais je ne peux pas le faire et je dois fournir une explication à l’équipe sur la raison pour laquelle je ne peux pas le faire, donc soit le périmètre de travail sera modifié pour faire ce que nous pouvons, soit je devrai contribuer dans l’espoir que cela sera ajouté au cœur et publié dans la prochaine version. J’ai donc besoin d’une confirmation de l’équipe de développement de Discourse quant à la faisabilité de cela.

En regardant également le dépôt principal GitHub - discourse/discourse: A platform for community discussion. Free, open, simple., je ne vois pas la section des problèmes à côté des Pull Requests, où les gens créent habituellement des problèmes décrivant si quelque chose est cassé ou manquant.

Les choses cassées vont dans Bug, les fonctionnalités manquantes dans Feature (ou dans le cas, par exemple, des points de terminaison de plugin Dev)

Utilisez-vous la branche stable ? Alors il y a pas mal de temps avant la prochaine version stable, mais sinon vous n’avez pas besoin d’attendre que les commits soient ajoutés à la dernière branche après la fusion de la PR.

1 « J'aime »

Salut @Moin , merci pour cette information !

J’utilise une configuration Docker pour Discourse et vous avez soulevé une bonne suggestion concernant la branche, oui, je pourrais peut-être la changer une fois le PR fusionné et ne pas attendre la sortie réelle.

En regardant app.yml, je vois qu’il utilise la version (branche) tests-passed, qui, d’après ce que je vois sur GIT, n’est probablement pas la meilleure à utiliser pour la stabilité. Laquelle est préférée, main ou passer sur le dernier tag ? Est-il possible de passer sur un tag du tout pour une configuration Docker ?

1 « J'aime »

tests-passed est le dernier : "tests-passed" is now "latest"

Main n’est pas recommandé pour une utilisation en production.

1 « J'aime »

@david , @Falco J’ai créé une PR, veuillez l’examiner et me faire savoir si quelque chose manque. J’ai besoin que cela progresse dès que possible, donc si vous pouviez le prioriser d’une manière ou d’une autre, je vous en serais très reconnaissant.

3 « J'aime »

@david , je voulais juste vous remercier pour la revue et la fusion si rapides de la PR.

2 « J'aime »