I componenti Glimmer sono attualmente supportati nelle route?
Sto ipotizzando che la risposta sia “no” per Discourse, ma sarei lieto di apprendere il contrario.
Sì, puoi usare i file .gjs per i modelli di route in Discourse in questo momento. Infatti, ne abbiamo appena convertiti molti oggi nel core! Dai un’occhiata a discourse/app/assets/javascripts/discourse/app/templates at main · discourse/discourse · GitHub per esempi.
“Qualcuno” è Discourse - abbiamo sponsorizzato lo sviluppo di ember-route-template, ed è nella nostra organizzazione GitHub 
Non siamo ancora sull’ultima versione di Ember 6.x, ma usiamo quell’addon per abilitare la funzionalità.
Oh, bellissimo! Grazie per la rapida risposta!
Ahah, non avevo nemmeno visto che era nel github di Discourse. Buon punto. 
Aggiungere una nuova route all’app si è rivelato molto poco intuitivo. Documenterò qui per gli altri.
Volevo aggiungere una route /print alla radice.
Il codice finale che ha funzionato per me è stato il seguente. county-fence è il nome del mio plugin, quindi sostituiscilo con il tuo.
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
C’è un modo per ottenere una pagina vuota senza il layout, le barre di navigazione o qualsiasi CSS del sito? Voglio usare il componente Glimmer, ma nessuno degli stili del sito web è utile per produrre una pagina stampabile.
Se si tratta solo di stile per una pagina effettivamente stampata e non ti dispiace la navbar e altro materiale quando visualizzi la pagina, puoi usare il selettore CSS @media print per modificare lo stile durante la stampa. Discourse nasconde già molte cose durante la stampa (discourse/app/assets/stylesheets/common/printer-friendly.scss at main · discourse/discourse · GitHub). Puoi visualizzare in anteprima la pagina utilizzando la modalità print media simulation nella modalità di ispezione di Firefox. Dovrebbe esserci una funzionalità equivalente nella modalità di ispezione di Chrome.
Se hai bisogno di una tela completamente bianca su cui lavorare, non solo in modalità di stampa ma anche nella normale navigazione web, puoi usare un po’ di astuzia CSS.
Supponiamo che il tuo componente glimmer abbia un div radice con id=\"print-component__root\", possiamo far sì che il CSS verifichi la sua esistenza con un selettore :has() (o semplicemente aggiungere/rimuovere una classe al body dal ciclo di vita del componente glimmer), e applicare selettivamente lo stile.
body:has(#print-component__root) {
header,
.avatar,
.sidebar-wrapper,
... {
all: unset !important; // all: unset potrebbe essere un po' troppo aggressivo
display: none !important;
}
}
#print-component__root {
// stile normale
}
Potrebbe esserci un modo migliore e più pulito per rimuovere effettivamente gli elementi DOM, ma il CSS è un buon workaround per resettare tutto.
Il mio SCSS non viene caricato. Qualche idea? Ho configurato i miei file secondo il plugin chat in core.
Ho in plugins.rb:
register_asset "stylesheets/common/index.scss"
In assets/stylesheets/common/index.scss:
@import "common";
In assets/stylesheets/common/common.scss:
body:has(#print-root) {
header,
.avatar,
.sidebar-wrapper {
all: unset; // all: unset potrebbe essere un po' troppo aggressivo
display: none !important;
}
}
Solo per assicurarmi che il problema sia nel caricamento dell’SCSS e non in una regola di stile che ti ho dato, prova ad aggiungere uno stile senza il selettore :has(). Qualcosa come:
.sidebar-wrapper {
outline: 5px solid red;
}
Proverei anche a riavviare il tuo server Rails. Ho avuto problemi in passato in cui l’aggiunta/rimozione di chiamate register_asset richiedeva un riavvio completo del container Docker.
:has().index.scss per verificare che non sia l’istruzione @import.d/rake assets:clobber tmp:clear e d/rails s.Finora non riesco a farlo caricare.
La maggior parte degli altri file causa un ricaricamento automatico nel browser. Questo non lo fa. Quindi penso che register_asset possa essere il problema. Penso che register asset cerchi automaticamente nella cartella degli asset? Tutti gli esempi che sto guardando indicano che è così.
d/rails c e DiscoursePluginRegistry.stylesheets rivelano:
"county-fence"=#Set: {"/src/plugins/county-fence/assets/stylesheets/common/index.scss"}
Quindi qualcosa sta succedendo. ^^
Ho trovato nei log di d/rails s: No such file or directory @ rb_sysopen - /src/app/assets/stylesheets/plugin-cf.scss.
Quindi, anche se il plugin è collegato simbolicamente nella cartella /plugins come county-fence, e il mio plugin è esplicitamente chiamato county-fence in plugins.rb, del codice sta leggendo il nome della directory sottostante plugin-cf e sta facendo supposizioni su quale sarà il nome compilato del CSS per il mio plugin.
È un bug o una funzionalità? 
Penso che la morale di questa storia sia non nominare in nessun caso la directory del tuo plugin con un nome diverso da quello corrispondente del tuo plugin. Un collegamento simbolico nominato correttamente non è sufficiente.
EDIT: anche register_asset \"stylesheets/common/index.scss\", plugin: \"county-fence\" è una soluzione che forza l’impostazione corretta del nome del plugin.
Sto riscontrando problemi con le regole sotto body:has() che vengono applicate. Non sembrano aggiornarsi nella pipeline di compilazione degli asset. Eseguo d/rake assets:clobber tmp:clear e riavvio il server con d/rails s e non si aggiornano ancora.
Ad esempio, posso inserire body { background-color: red !important; } nella sezione body:has() e non appare affatto negli stili per l’elemento body. Non è solo che viene sovrascritto: semplicemente non è presente negli “stili” negli strumenti per sviluppatori.
Quando inserisco la stessa riga di CSS al di fuori di body:has(), viene visualizzata correttamente.
document.querySelector("body:has(#print-root)") !== null nella console del browser restituisce true. E alcune regole da body:has() vengono applicate.
Mi chiedo se ci possano essere regole nella pipeline di generazione degli asset che impediscano l’applicazione di queste modifiche.
Penso che la mia soluzione per questo sia semplicemente includere gli stili direttamente nel componente Glimmer per la pagina. È l’unica cosa che ho provato che funziona in modo coerente. E poi non devo preoccuparmi delle regole CSS condizionali.
La pipeline di compilazione CSS mi sta dando un sacco di problemi: la trovo davvero incoerente nel refresh, nell’applicazione delle regole… le cose scompaiono e non so perché. Non so se questo abbia a che fare con l’esecuzione in un container Docker? Ora ho eliminato del tutto il mio symlink alla cartella dei plugin: credo che stesse causando problemi con il mount del volume Docker e il file watching/ricompilazione. Probabilmente posso creare un repository minimale per riprodurre questi problemi… vedrò se riesco a farlo e a pubblicarlo nei prossimi giorni.
Un seguito a questo…
Un iframe renderizzato da Stripe sta ora causando il rendering di una pagina vuota nella parte inferiore del mio layout di stampa. L’iframe è codificato con display: block !important direttamente sull’elemento.
Penso che risolverò questo particolare bug eliminando l’iframe quando questo percorso viene caricato… (A proposito, Stripe sta renderizzando un div largo quanto la pagina che rileva tutti gli eventi di clic - il che sembra una violazione della privacy… Credo che provenga dal plugin delle sottoscrizioni.)
Ma sto guardando al futuro e prevedo una lunga strada di risoluzione dei problemi “acchiappa la talpa” nella pagina di stampa. Qualsiasi cosa in futuro che introduca un nuovo elemento nel layout, anche se non è visibilmente evidente, potrebbe causare malfunzionamenti nella stampa.
Non è davvero uno scenario ideale per me ereditare il layout del sito per questo percorso. C’è un modo per disattivare o impostare il mio layout?