¿Podemos usar `.gjs` para plantillas de rutas?

¿Los componentes Glimmer son compatibles actualmente en las rutas?

Supongo que la respuesta es “no” para Discourse, pero me complacería saber lo contrario.

2 Me gusta

Sí, puedes usar archivos .gjs para las plantillas de ruta en Discourse ahora mismo. De hecho, ¡acabamos de convertir un montón de ellos hoy en el núcleo! Echa un vistazo a discourse/app/assets/javascripts/discourse/app/templates at main · discourse/discourse · GitHub para ver ejemplos.

“Alguien” es Discourse: patrocinamos el desarrollo de ember-route-template, y está en nuestra organización de GitHub :wink:

Todavía no estamos en la última versión de Ember 6.x, pero usamos ese complemento para habilitar la funcionalidad.

5 Me gusta

¡Oh, genial! ¡Gracias por la rápida respuesta!

Jaja, ni siquiera vi que estaba en el GitHub de Discourse. Buen punto. :slight_smile:

3 Me gusta

Agregar una nueva ruta a la aplicación me resultó muy poco obvio. Lo documentaré aquí para otros.

Quería agregar una ruta /print en la raíz.

El código final que funcionó para mí fue el siguiente. county-fence es el nombre de mi plugin, así que reemplázalo con el tuyo.

Ruta de Ember

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 es una página de impresión personalizada!" };
  }
}

assets/javascripts/discourse/templates/print.gjs

import RouteTemplate from "ember-route-template";
import ...;

export default RouteTemplate(
  <template>
    ...
  </template>
)

Ruta de API

plugin.rb

after_initialize do
  require_relative "app/controllers/print_controller"
end

app/controllers/print_controller.rb

# frozen_string_literal: true
# Códigos de estado 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: "¡delicioso!" }
  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
4 Me gusta

¿Hay alguna forma de obtener una página en blanco sin el diseño, las barras de navegación ni ningún CSS del sitio? Quiero usar el componente Glimmer, pero ninguno de los estilos del sitio web es útil para producir una página de impresión.

Si solo se trata de estilo para una página que se va a imprimir y no te importa la barra de navegación y otros elementos adicionales al ver la página, puedes usar el selector CSS @media print para cambiar el estilo al imprimir. Discourse ya oculta muchas cosas al imprimir (discourse/app/assets/stylesheets/common/printer-friendly.scss at main · discourse/discourse · GitHub). Puedes previsualizar la página usando el modo de simulación de medios de impresión en el modo de inspección de Firefox. Debería haber una función equivalente en el modo de inspección de Chrome.

Si necesitas un lienzo completamente en blanco para trabajar, no solo en el modo de impresión sino también en la navegación web normal, puedes usar un truco de CSS.
Supongamos que tu componente de brillo tiene un div raíz con id=\"print-component__root\", podemos hacer que CSS verifique su existencia con un selector :has() (o simplemente agregar/eliminar una clase al cuerpo desde el ciclo de vida del componente de brillo) y aplicar estilos selectivamente.

body:has(#print-component__root) {
  header,
  .avatar,
  .sidebar-wrapper,
  ... {
    all: unset !important;  // all: unset podría ser un poco agresivo
    display: none !important;
  }
}

#print-component__root {
  // estilo normal
}

Podría haber una forma mejor y más limpia que realmente elimine los elementos DOM, pero el CSS es una buena solución alternativa para restablecer todo.

2 Me gusta

Mi SCSS no se está cargando. ¿Alguna idea? Configuré mis archivos según el plugin de chat en core.

Tengo en plugins.rb:

register_asset "stylesheets/common/index.scss"

En assets/stylesheets/common/index.scss:

@import "common";

En assets/stylesheets/common/common.scss:

body:has(#print-root) {
  header,
  .avatar,
  .sidebar-wrapper {
    all: unset;  // all: unset podría ser un poco agresivo
    display: none !important;
  }
}

Solo para asegurarme de que el problema está en la carga del SCSS y no en una regla de estilo que te di, intenta agregar un estilo sin el selector :has(). Algo como:

.sidebar-wrapper {
  outline: 5px solid red;
}

También intentaría reiniciar tu servidor de Rails. He tenido problemas en el pasado donde agregar/eliminar llamadas a register_asset requería reiniciar completamente el contenedor de Docker.

2 Me gusta
  • Eliminé el selector :has().
  • Coloqué el código en index.scss para verificar que no sea la declaración @import.
  • Ejecuté d/rake assets:clobber tmp:clear y d/rails s.

Nada hasta ahora ha conseguido que se cargue.

La mayoría de los otros archivos provocan una recarga automática en el navegador. Este no lo hace. Así que creo que register_asset podría ser donde reside el problema. Creo que register asset busca automáticamente en la carpeta de assets. Todos los ejemplos que estoy viendo indican que este es el caso.

1 me gusta

d/rails c y DiscoursePluginRegistry.stylesheets revelan:

"county-fence"=#Set: {"/src/plugins/county-fence/assets/stylesheets/common/index.scss"}

Entonces, algo está sucediendo. ^^

1 me gusta

Encontré en los registros de d/rails s: No such file or directory @ rb_sysopen - /src/app/assets/stylesheets/plugin-cf.scss.

Entonces, aunque el plugin está enlazado simbólicamente en la carpeta /plugins como county-fence, y mi plugin se llama explícitamente county-fence en plugins.rb, algún código está leyendo el nombre del directorio subyacente plugin-cf y haciendo suposiciones sobre cuál será el nombre compilado de CSS para mi plugin.

¿Es esto un error o una característica? :smiley:

Creo que la moraleja de esta historia es no nombrar el directorio de su plugin bajo ninguna circunstancia de manera diferente al nombre coincidente de su plugin. Un enlace simbólico nombrado correctamente no es suficiente.

EDITAR: también register_asset \"stylesheets/common/index.scss\", plugin: \"county-fence\" es una solución que obliga a que el nombre del plugin se establezca correctamente.

Tengo problemas con la aplicación de las reglas en body:has(). No parecen actualizarse en el pipeline de compilación de assets. Ejecuto d/rake assets:clobber tmp:clear y reinicio el servidor con d/rails s y todavía no se actualizan.

Por ejemplo, puedo poner body { background-color: red !important; } en la sección body:has() y no aparece en absoluto en los estilos para el elemento body. No es solo que esté siendo anulado, simplemente no está presente en los “estilos” en las devtools.

Cuando coloco la misma línea de CSS fuera de body:has(), se muestra bien.

document.querySelector("body:has(#print-root)") !== null en la consola del navegador devuelve true. Y algunas reglas de body:has() se están aplicando.

Me pregunto si podría haber reglas en el pipeline de generación de assets que impidan que estos cambios se apliquen.

Creo que mi solución para esto es simplemente incluir los estilos directamente en el componente de Glimmer para la página. Es lo único que he probado que funciona de manera consistente. Y así no tengo que lidiar con las reglas CSS condicionales.

El pipeline de compilación de CSS me ha estado dando muchísimos problemas: me parece que es muy inconsistente a la hora de refrescar, aplicar reglas… las cosas desaparecen y no sé por qué. ¿No sé si esto tiene algo que ver con la ejecución en un contenedor Docker? Ahora he eliminado por completo mi enlace simbólico a la carpeta de plugins; creo que eso estaba causando problemas con el montaje del volumen de Docker y la observación/recompilación de archivos. Probablemente pueda crear un repositorio mínimo para reproducir estos problemas… veré si puedo hacerlo y publicarlo en los próximos días.

Una continuación de esto…

Un iframe que se está renderizando desde Stripe ahora está causando que se renderice una página en blanco en la parte inferior de mi diseño de impresión. El iframe está codificado con display: block !important directamente en el elemento.

Creo que solucionaré este error en particular eliminando el iframe cuando se cargue esta ruta… (Por cierto, Stripe está renderizando un div de ancho de página que detecta todos los eventos de clic, lo que parece una invasión de la privacidad… Creo que esto es del plugin de suscripciones).

Pero estoy mirando hacia el futuro y preveo un largo camino de solución de problemas de tipo “topo” en la página de impresión. Cualquier cosa en el futuro que introduzca un nuevo elemento en el diseño, incluso si no es visible, podría hacer que las impresiones funcionen mal.

Realmente no es un escenario ideal para mí heredar el diseño del sitio para esta ruta. ¿Hay alguna forma de optar por no participar o establecer mi propio diseño?