Os componentes Glimmer são atualmente suportados em rotas?
Estou imaginando que a resposta é “não” para o Discourse, mas ficaria feliz em saber o contrário.
Sim, você pode usar arquivos .gjs para modelos de rota no Discourse agora mesmo. Na verdade, acabamos de converter vários deles hoje no core! Confira discourse/app/assets/javascripts/discourse/app/templates at main · discourse/discourse · GitHub para exemplos.
“Alguém” é o Discourse - nós patrocinamos o desenvolvimento do ember-route-template, e ele está em nossa organização do GitHub 
Ainda não estamos no Ember 6.x mais recente, mas usamos esse addon para habilitar a funcionalidade.
Oh, que ótimo! Obrigado pela resposta rápida!
Haha, eu nem vi que estava no GitHub do Discourse. Bom ponto. 
Adicionar uma nova rota ao aplicativo foi muito pouco óbvio. Vou documentar aqui para outros.
Eu queria adicionar uma rota /print na raiz.
O código final que funcionou para mim foi o seguinte. county-fence é o nome do meu plugin, então substitua-o pelo seu próprio.
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: "Esta é uma página de impressão personalizada!" };
}
}
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
# Códigos de status HTTP: 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 uma maneira de obter uma página em branco sem o layout, as barras de navegação ou qualquer CSS do site? Quero usar o componente Glimmer, mas nenhum dos estilos do site é útil para produzir uma página de impressão.
Se for apenas estilo para uma página realmente impressa, e você não se importa com a barra de navegação e outros elementos extras ao visualizar a página, você pode usar o seletor CSS @media print para alterar o estilo ao imprimir. O Discourse já oculta muitas coisas durante a impressão (discourse/app/assets/stylesheets/common/printer-friendly.scss at main · discourse/discourse · GitHub). Você pode pré-visualizar a página usando o modo print media simulation no modo de inspeção do Firefox. Deve haver um recurso equivalente no modo de inspeção do Chrome.
Se você precisar de uma tela em branco completa para trabalhar, não apenas no modo de impressão, mas também na navegação normal na web, você pode usar um pouco de truque de CSS.
Suponha que seu componente glimmer tenha uma div raiz com id=\"print-component__root\", podemos deixar o CSS verificar sua existência com um seletor :has() (ou simplesmente adicionar/remover uma classe do corpo do ciclo de vida do componente glimmer), e aplicar estilos seletivamente.
body:has(#print-component__root) {
header,
.avatar,
.sidebar-wrapper,
... {
all: unset !important; // all: unset pode ser um pouco agressivo demais
display: none !important;
}
}
#print-component__root {
// estilo normal
}
Pode haver uma maneira melhor e mais limpa que realmente remova os elementos DOM, mas o CSS é uma boa solução alternativa para redefinir tudo.
Meu SCSS não está carregando. Alguma ideia? Configurei meus arquivos conforme o plugin de chat no core.
Tenho em plugins.rb:
register_asset "stylesheets/common/index.scss"
Em assets/stylesheets/common/index.scss:
@import "common";
Em assets/stylesheets/common/common.scss:
body:has(#print-root) {
header,
.avatar,
.sidebar-wrapper {
all: unset; // all: unset pode ser um pouco agressivo demais
display: none !important;
}
}
Apenas para garantir que o problema seja com o carregamento do SCSS e não com uma regra de estilo que lhe dei, tente adicionar um estilo sem o seletor :has(). Algo como:
.sidebar-wrapper {
outline: 5px solid red;
}
Eu também tentaria reiniciar seu servidor Rails. Tive problemas no passado em que adicionar/remover chamadas register_asset exigia uma reinicialização completa do contêiner Docker.
:has().index.scss para verificar se não é a instrução @import.d/rake assets:clobber tmp:clear e d/rails s.Nada até agora está fazendo com que ele carregue.
A maioria dos outros arquivos causa uma recarga automática no navegador. Este não está fazendo isso. Então, acho que register_asset pode ser onde o problema reside. Acho que register asset procura automaticamente na pasta de ativos? Todos os exemplos que estou vendo indicam que este é o caso.
d/rails c e DiscoursePluginRegistry.stylesheets revelam:
"county-fence"=#Set: {"/src/plugins/county-fence/assets/stylesheets/common/index.scss"}
Então, algo está acontecendo. ^^
Encontrei nos logs do d/rails s: No such file or directory @ rb_sysopen - /src/app/assets/stylesheets/plugin-cf.scss.
Portanto, embora o plugin esteja vinculado simbolicamente na pasta /plugins como county-fence, e meu plugin seja explicitamente nomeado county-fence em plugins.rb, algum código está lendo o nome do diretório subjacente plugin-cf e fazendo suposições sobre qual será o nome compilado do CSS para o meu plugin.
Isso é um bug ou um recurso? 
Acho que a moral desta história é não nomeie seu diretório de plugin sob nenhuma circunstância com algo diferente do nome correspondente do seu plugin. Um link simbólico nomeado corretamente não é suficiente.
EDIT: também register_asset \"stylesheets/common/index.scss\", plugin: \"county-fence\" é uma solução alternativa que força o nome do plugin a ser definido corretamente.
Estou tendo problemas com as regras em body:has() sendo aplicadas. Elas não parecem estar sendo atualizadas no pipeline de compilação de assets. Eu executo d/rake assets:clobber tmp:clear e reinicio o servidor com d/rails s e elas ainda não são atualizadas.
Por exemplo, posso colocar body { background-color: red !important; } na seção body:has() e isso não aparece em nada nos estilos para o elemento body. Não é apenas que está sendo substituído - simplesmente não está presente em “estilos” nas ferramentas de desenvolvedor.
Quando coloco a mesma linha de CSS fora de body:has(), ela é exibida normalmente.
document.querySelector("body:has(#print-root)") !== null no console do navegador retorna true. E algumas regras de body:has() estão sendo aplicadas.
Estou imaginando se pode haver regras no pipeline de geração de assets que impedem que essas alterações sejam aplicadas.
Acho que a minha solução para isso é apenas incluir os estilos diretamente no componente Glimmer para a página. Essa é a única coisa que tentei que funciona de forma consistente. E então eu não tenho que me preocupar com as regras CSS condicionais.
O pipeline de compilação CSS tem me dado muitos problemas - estou achando que é realmente inconsistente em atualizar, aplicar regras… as coisas desaparecem e eu não sei por quê. Não sei se isso tem algo a ver com a execução em um contêiner Docker? Agora abandonei completamente meu link simbólico para a pasta de plugins - acredito que isso estava causando problemas com o volume de montagem do Docker e o monitoramento/recompilação de arquivos. Provavelmente posso criar um repositório mínimo para reproduzir esses problemas… verei se consigo fazer isso e publicá-lo nos próximos dias.
Uma atualização sobre isso…
Um iframe sendo renderizado pelo Stripe agora está causando uma página em branco na parte inferior do meu layout de impressão. O iframe está codificado com display: block !important diretamente no elemento.
Acho que vou contornar este bug específico excluindo o iframe quando esta rota for carregada… (A propósito, o Stripe está renderizando uma div de largura total que detecta todos os eventos de clique - o que parece uma invasão de privacidade considerável… Acredito que isso seja do plugin de assinaturas.)
Mas estou olhando para o futuro e prevendo um longo caminho de solução de problemas “whack-a-mole” na página de impressão. Qualquer coisa no futuro que introduza um novo elemento no layout, mesmo que não seja visivelmente perceptível, pode fazer com que as impressões funcionem mal.
Realmente não é um cenário ideal para mim herdar o layout do site para esta rota. Existe alguma maneira de eu optar por não participar ou definir meu próprio layout?