Les composants Glimmer sont-ils actuellement pris en charge dans les routes ?
Je suppose que la réponse est « non » pour Discourse, mais je serais ravi d’apprendre le contraire.
Oui, vous pouvez utiliser les fichiers .gjs pour les modèles de route dans Discourse dès maintenant. En fait, nous en avons converti un grand nombre aujourd’hui dans le cœur ! Consultez \u003chttps://github.com/discourse/discourse/tree/main/app/assets/javascripts/discourse/app/templates\u003e pour des exemples.
« quelqu’un » c’est Discourse - nous avons sponsorisé le développement d’ember-route-template, et il est dans notre organisation GitHub 
Nous ne sommes pas encore sur la dernière version d’Ember 6.x, mais nous utilisons cet addon pour activer la fonctionnalité.
Magnifique ! Merci pour votre réponse rapide !
Haha, je n’avais même pas vu que c’était sur le github de Discourse. Bonne remarque. 
L’ajout d’une nouvelle route à l’application s’est avéré très peu évident. Je vais documenter ici pour les autres.
Je voulais ajouter une route /print à la racine.
Le code final qui a fonctionné pour moi était le suivant. county-fence est le nom de mon plugin, alors remplacez-le par le vôtre.
assets/javascripts/discourse/routes/county-fence-route-map.js.es6
export default function() {
this.route('print', { path: '/print' });
}
assets/javascripts/discourse/routes/print.js
import Route from "@ember/routing/route";
export default class PrintRoute extends Route {
model() {
return { message: "This is a custom print page!" };
}
}
assets/javascripts/discourse/templates/print.gjs
import RouteTemplate from "ember-route-template";
import ...;
export default RouteTemplate(
<template>
...
</template>
)
plugin.rb
after_initialize do
require_relative "app/controllers/print_controller"
end
app/controllers/print_controller.rb
# frozen_string_literal: true
# HTTP Status codes: https://github.com/discourse/discourse/blob/main/lib/discourse.rb
class ::CountyFence::PrintController < ::ApplicationController
requires_plugin CountyFence::PLUGIN_NAME
def save_print
end
def list_prints
render json: { name: "donut", description: "delicious!" }
end
def get_print
end
end
Discourse::Application.routes.append do
post "/print" => "county_fence/print#save_print"
get "/print" => "county_fence/print#list_prints"
get "/print/:id" => "county_fence/print#get_print"
end
Existe-t-il un moyen d’obtenir une page vierge sans la mise en page, les barres de navigation ou tout le CSS du site ? Je veux utiliser le composant Glimmer, mais aucun des styles du site Web n’est utile pour produire une page d’impression.
Si c’est juste du style pour une page réellement imprimée, et que vous ne vous souciez pas de la barre de navigation et des éléments supplémentaires lors de la visualisation de la page, vous pouvez utiliser le sélecteur CSS @media print pour modifier le style lors de l’impression. Discourse masque déjà beaucoup de choses lors de l’impression (discourse/app/assets/stylesheets/common/printer-friendly.scss at main · discourse/discourse · GitHub). Vous pouvez prévisualiser la page en utilisant le mode print media simulation dans le mode d’inspection de Firefox. Il devrait y avoir une fonctionnalité équivalente dans le mode d’inspection de Chrome.
Si vous avez besoin d’une toile vierge complète pour travailler, non seulement en mode impression mais aussi en navigation Web normale, vous pouvez utiliser une astuce CSS.
Supposons que votre composant Glimmer ait une div racine avec id=\"print-component__root\", nous pouvons laisser CSS vérifier son existence avec un sélecteur :has() (ou simplement ajouter/supprimer une classe au corps à partir du cycle de vie du composant Glimmer), et appliquer sélectivement le style.
body:has(#print-component__root) {
header,
.avatar,
.sidebar-wrapper,
... {
all: unset !important; // all: unset pourrait être un peu trop agressif
display: none !important;
}
}
#print-component__root {
// style normal
}
Il pourrait y avoir une meilleure façon, plus propre, qui supprimerait réellement les éléments DOM, mais le CSS est une bonne solution de contournement pour tout réinitialiser.
Mon SCSS ne se charge pas. Des idées ? J’ai configuré mes fichiers selon le plugin de chat dans core.
J’ai dans plugins.rb :
register_asset "stylesheets/common/index.scss"
Dans assets/stylesheets/common/index.scss :
@import "common";
Dans assets/stylesheets/common/common.scss :
body:has(#print-root) {
header,
.avatar,
.sidebar-wrapper {
all: unset; // all: unset pourrait être un peu trop agressif
display: none !important;
}
}
Juste pour être sûr que le problème vient du chargement du SCSS et non d’une règle de style que je vous ai donnée, essayez d’ajouter un style sans le sélecteur :has(). Quelque chose comme :
.sidebar-wrapper {
outline: 5px solid red;
}
J’essaierais aussi de redémarrer votre serveur Rails. J’ai eu des problèmes par le passé où l’ajout/la suppression d’appels register_asset nécessitait un redémarrage complet du conteneur Docker.
:has().index.scss pour vérifier que ce n’est pas l’instruction @import.d/rake assets:clobber tmp:clear et d/rails s.Rien jusqu’à présent ne permet de le charger.
La plupart des autres fichiers provoquent un rechargement automatique dans le navigateur. Celui-ci ne le fait pas. Je pense donc que register_asset pourrait être à l’origine du problème. Je pense que register asset recherche automatiquement dans le dossier assets ? Tous les exemples que je consulte l’indiquent.
d/rails c et DiscoursePluginRegistry.stylesheets révèlent :
`“county-fence” => #<Set: {“/src/plugins/county-fence/assets/stylesheets/common/index.scss”}>
Donc, quelque chose se passe. ^^
J’ai trouvé dans les logs de d/rails s : No such file or directory @ rb_sysopen - /src/app/assets/stylesheets/plugin-cf.scss.
Donc, même si le plugin est lié symboliquement dans le dossier /plugins sous le nom county-fence, et que mon plugin est explicitement nommé county-fence dans plugins.rb, certains codes lisent le nom du répertoire sous-jacent plugin-cf et font des suppositions sur le nom compilé de la feuille de style CSS pour mon plugin.
Est-ce un bug ou une fonctionnalité ? 
Je pense que la morale de cette histoire est ne nommez en aucun cas le répertoire de votre plugin autrement que par le nom correspondant de votre plugin. Un lien symbolique correctement nommé n’est pas suffisant.
EDIT : également register_asset \"stylesheets/common/index.scss\", plugin: \"county-fence\" est une solution de contournement qui force le nom du plugin à être défini correctement.
J’ai des problèmes avec l’application des règles sous body:has(). Elles ne semblent pas être mises à jour dans le pipeline de compilation des assets. J’exécute d/rake assets:clobber tmp:clear et je redémarre le serveur avec d/rails s et elles ne se mettent toujours pas à jour.
Par exemple, je peux mettre body { background-color: red !important; } dans la section body:has() et cela n’apparaît pas du tout dans les styles de l’élément body. Ce n’est pas juste qu’elle est remplacée - elle n’est tout simplement pas présente dans les “styles” des outils de développement.
Lorsque je place la même ligne de CSS en dehors de body:has(), elle s’affiche correctement.
document.querySelector("body:has(#print-root)") !== null dans la console du navigateur renvoie true. Et certaines règles de body:has() sont appliquées.
Je me demande s’il pourrait y avoir des règles dans le pipeline de génération d’assets qui empêchent ces changements d’être appliqués.
Je pense que ma solution pour cela consiste simplement à inclure les styles directement dans le composant Glimmer pour la page. C’est la seule chose que j’ai essayée et qui fonctionne de manière cohérente. Et ensuite, je n’ai pas à me soucier des règles CSS conditionnelles.
Le pipeline de compilation CSS m’a causé d’innombrables problèmes - je constate qu’il est très incohérent quant au rafraîchissement, à l’application des règles… les choses disparaissent et je ne sais pas pourquoi. Je ne sais pas si cela a quelque chose à voir avec l’exécution dans un conteneur Docker ? J’ai maintenant complètement supprimé mon lien symbolique vers le dossier des plugins - je crois que cela causait des problèmes avec le montage de volume Docker et la surveillance/recompilation des fichiers. Je peux probablement créer un dépôt minimal pour reproduire ces problèmes… Je vais voir si je peux le faire et le publier dans les prochains jours.
Une suite à cela…
Un iframe rendu par Stripe provoque maintenant une page vierge en bas de ma mise en page d’impression. L’iframe est codé en dur avec display: block !important directement sur l’élément.
Je pense que je vais contourner ce bug particulier en supprimant l’iframe lorsque cette route se charge… (Soit dit en passant, Stripe rend un div pleine largeur qui détecte tous les événements de clic - ce qui semble être une violation de la vie privée… Je crois que cela provient du plugin d’abonnement.)
Mais je regarde vers l’avenir et je prévois une longue route de dépannage de type “whack-a-mole” sur la page d’impression. Tout ce qui introduira un nouvel élément dans la mise en page à l’avenir, même s’il n’est pas visible, pourrait faire dysfonctionner les impressions.
Ce n’est vraiment pas un scénario idéal pour moi d’hériter de la mise en page du site pour cette route. Y a-t-il un moyen de me désinscrire ou de définir ma propre mise en page ?