No se puede colocar la plantilla en la salida deseada

Estoy intentando colocar una plantilla en un outlet de plugin específico en mi javascripts/discourse/initializers/persistent-banner.gjs.
Código:

import Component from "@glimmer/component";
import { apiInitializer } from "discourse/lib/api";

banner_plugin_outlet = settings.banner_position

export default apiInitializer("1.14.0", (api) => {
  try {
    banner_plugin_outlet = settings.banner_position
    api.renderInOutlet(
      banner_plugin_outlet,
      class persistentbanner extends Component {
        get bannerIsFilled() {
          if (settings.banner_text_content == "") {
            return false;
          } else if (settings.banner_visible == "hide") {
            return false;
          } else {
            return true;
          }
        }
        <template>
          {{#if this.bannerIsFilled}}
            <div class='persistent-banner'>
              <p>
                {{html_safe (theme-setting 'banner_text_content')}}
              </p>
            </div>
          {{/if}}
        </template>
      }
    );
  } catch (e) {
    console.log(e);
  }
}

Pero el HTML en la etiqueta <template> no se muestra en la ubicación del outlet. De hecho, no se muestra en absoluto. ¿Qué estoy haciendo mal?
Enlace del repositorio: GitHub - NateDhaliwal/discourse-persistent-banner: A theme component for Discourse that cannot be closed by the user.

1 me gusta

No uses un inicializador para esto. Usa la carpeta de conectores. Hay muchísimos ejemplos.

2 Me gusta

La razón es que hay diferentes outlets que se pueden seleccionar.
Adapté este código del repositorio de Notification Banner.

2 Me gusta

Ah, entendido. Sim, faz sentido. Desculpe, não tinha certeza da sua intenção funcional. Eu deveria ter lido o código com mais detalhes.

1 me gusta

Aquí tienes algunas cosas para que vuelvas a empezar:

  • este archivo tiene un paréntesis de cierre que falta al final de tu llamada a apiInitializer - eso simplemente no funcionará.

Al solucionar ese problema, veo más errores.

  • banner_plugin_outlet no está declarado - necesitas un const aquí.

    ¿Lo asignas dos veces? Sospecho que no lo necesitas dos veces :slight_smile:

    banner_plugin_outlet = settings.banner_position
    
    export default apiInitializer("1.14.0", (api) => {
      try {
        banner_plugin_outlet = settings.banner_position
    
  • Te faltan importaciones:

    import { htmlSafe } from "@ember/template";
    import themeSetting from "discourse/helpers/theme-setting";
    
  • … pero no pude hacer que themeSetting funcionara como un helper aquí. No hay error, solo está en blanco, así que prueba este código en su lugar:

            get bannerTextContent() {
              return settings.banner_text_content;
            }
            <template>
              {{#if this.bannerIsFilled}}
                <div class='persistent-banner'>
                  <p>
                    {{htmlSafe this.bannerTextContent}}
    
  • Siempre revisa la consola en busca de errores.

6 Me gusta

¡Importé htmlSafe y funcionó de maravilla!
¡Muchas gracias!

2 Me gusta

Sí, el ayudante no funciona (y no es necesario) en gjs. Definir un getter está bien. Pero si quieres evitar eso, puedes referenciar directamente el “global” settings desde la plantilla:

<template>
  {{htmlSafe settings.banner_text_content}}
</template>
4 Me gusta

¡Gracias! ¡Eso no pareció muy transparente! :sweat_smile:

3 Me gusta

Sí, eso es justo. Mejoremos los mensajes de error:


5 Me gusta

Gracias. Esto realmente ayuda con la experiencia del desarrollador.

Lo que, como sabemos, ha mejorado drásticamente con .gjs sobre los widgets.

sin embargo

Hay muchos errores muy extraños que puedes obtener al usar componentes gjs que no facilitan la búsqueda de los problemas.

Por ejemplo, estropeemos el nombre del ayudante:
{{html_safe this.bannerTextContent}}

Conduce al clásico:

program.js:100 Uncaught (in promise) TypeError: Invalid value used as weak map key at WeakMap.set (<anonymous>)

(esto también sucede aquí con un nombre válido si olvidas la importación)

¿Qué demonios? :sweat_smile: Hay muchos de estos ejemplos.

Supongo que esta es una desventaja de usar un framework.

3 Me gusta

¡Ay, ese es malo!

Cuando intento localmente, veo:

¿Dónde viste el error de WeakMap? ¿En un sitio de producción? Si es así… quizás esta sea una de las comprobaciones que Ember optimiza y elimina de las compilaciones de producción para mejorar el rendimiento.

Si puedes, siempre recomendaría desarrollar temas/plugins en un entorno de desarrollo adecuado; hay muchos casos como este en los que la experiencia será mejor.

4 Me gusta

Sí, el sitio de producción utiliza la Theme CLI ( que supongo que es una de sus desventajas, a pesar de que por lo demás es un gran flujo de trabajo.)

[quote=“David Taylor, post:12, topic:330650, username:david”]ninguna de las comprobaciones que ember optimiza en las compilaciones de producción para mejorar el rendimiento.
[/quote]

Tiene todo el sentido.

Sí, con los plugins es mi opción preferida, pero con los TC existe una gran tentación de desarrollar contra un sitio de producción debido a la inmediatez de la retroalimentación (¡si no siempre es muy útil!)

Pero me acabo de dar cuenta de que puedes entrar en localhost con la CLI y funciona.

¡Así que duh!

image

¡Lo usaré en el futuro! :rocket:

No tengo idea de por qué pensé que eso no sería posible :blush: :sweat_smile:

Como siempre, gracias por tu ayuda, me ha ahorrado mucho tiempo (en el futuro :slight_smile: )

2 Me gusta

¡Sí! Localhost con un theme-cli es como intento trabajar y lo que recomiendo a otras personas. Definitivamente podemos mejorar la documentación de estos flujos de trabajo recomendados :eyes:

El otro consejo es que discourse.theme-creator.io se ejecuta con activos de Ember en modo de desarrollo. Así que también debería tener mensajes de error más agradables.

4 Me gusta

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.