Não é possível colocar o molde na saída desejada

[NateDhaliwal]

Estou tentando colocar um template em um outlet de plugin específico em meu 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);
  }
}

Mas o HTML na tag <template> não é exibido na localização do outlet. Na verdade, ele não é exibido de forma alguma. O que estou fazendo de errado?
Link do repositório: GitHub - NateDhaliwal/discourse-persistent-banner: A theme component for Discourse that cannot be closed by the user.

[merefield (Robert)]

Não use um inicializador para isso? Use a pasta de conectores. Há muitos exemplos.

[NateDhaliwal]

O motivo é que existem diferentes saídas que podem ser selecionadas.
Adaptei este código do repositório do Notification Banner.

[merefield (Robert)]

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

[merefield (Robert)]

Algumas coisas para você voltar a funcionar:

• este arquivo tem um parêntese de fechamento faltando no final da sua chamada apiInitializer - isso simplesmente não funcionará.

Ao corrigir esse problema, vejo mais erros.

• banner_plugin_outlet não está declarado - você precisa de um const aqui.

  você o atribui duas vezes? você não precisa dele duas vezes, suspeito

  banner_plugin_outlet = settings.banner_position
  
  export default apiInitializer("1.14.0", (api) => {
    try {
      banner_plugin_outlet = settings.banner_position
  

• Você está perdendo importações:

  import { htmlSafe } from "@ember/template";
  import themeSetting from "discourse/helpers/theme-setting";
  

• … mas eu não consegui fazer themeSetting funcionar como um helper aqui. Nenhum erro, apenas em branco, então tente este código em vez disso:

          get bannerTextContent() {
            return settings.banner_text_content;
          }
          <template>
            {{#if this.bannerIsFilled}}
              <div class='persistent-banner'>
                <p>
                  {{htmlSafe this.bannerTextContent}}
  

• Sempre verifique o console em busca de erros.

[NateDhaliwal]

Eu importei o htmlSafe e funcionou perfeitamente!
Muito obrigado!

[david (David Taylor)]

@merefield

Não consegui fazer o themeSetting funcionar como um helper aqui. Sem erro, apenas em branco, então tente este código em vez disso:

        get bannerTextContent() {
          return settings.banner_text_content;
        }
        <template>
          {{#if this.bannerIsFilled}}
            <div class='persistent-banner'>
              <p>
                {{htmlSafe this.bannerTextContent}}

Sim, o helper não funciona (e não é necessário) em gjs. Definir um getter está bom. Mas se você quiser evitar isso, pode referenciar o “global” settings diretamente do template:

<template>
  {{htmlSafe settings.banner_text_content}}
</template>

[merefield (Robert)]

Obrigado. Isso não pareceu muito transparente!

[david (David Taylor)]

Sim, isso é justo. Vamos melhorar as mensagens de erro:

DEV: Improve error messages for legacy theme helpers in gjs

[merefield (Robert)]

Obrigado. Isso realmente ajuda na experiência do desenvolvedor.

Que, como sabemos, melhorou drasticamente com .gjs em vez de widgets.

No entanto

Existem muitos erros muito estranhos que você pode obter ao usar componentes gjs que não facilitam a localização dos problemas.

Por exemplo, vamos estragar o nome do helper:
{{html_safe this.bannerTextContent}}

Leva ao clássico:

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

(isso também acontece aqui com um nome válido se você esquecer a importação)

Diga o quê?! Existem muitos desses exemplos.

Acho que essa é uma desvantagem de usar um framework?

[david (David Taylor)]

Ai, isso é grave!

Quando tento localmente, vejo:

Onde você viu o erro WeakMap? Em um site de produção? Se sim… talvez esta seja uma das verificações que o ember otimiza para fora das compilações de produção para melhorar o desempenho.

Se puder, eu sempre recomendaria desenvolver temas/plugins em um ambiente de desenvolvimento adequado - existem muitos casos como este em que a experiência será melhor.

[merefield (Robert)]

Sim, o site de produção usando o Theme CLI ( que eu acho que é uma de suas desvantagens, apesar de seu fluxo de trabalho, que de outra forma é ótimo?)

[quote=“David Taylor, post:12, topic:330650, username:david”]nenhuma das verificações que o ember otimiza fora das compilações de produção para melhorar o desempenho.
[/quote]

Isso faz todo o sentido.

@david

Eu sempre recomendaria desenvolver temas … em um ambiente de desenvolvimento adequado

Sim, com plugins é o meu preferido, mas com TCs há uma boa tentação de desenvolver contra um site de produção por causa da imediatidade do feedback (se não for sempre muito útil!)

Mas acabei de perceber, você pode entrar em localhost com o CLI e funciona.

Então, duh!

Eu usarei isso daqui para frente!

Não tenho ideia de por que pensei que isso não seria possível

Como sempre, obrigado pela sua ajuda, isso me poupou muito tempo (no futuro )

[david (David Taylor)]

Sim! O Localhost com um theme-cli é como eu tento trabalhar e o que eu recomendo para outras pessoas. Definitivamente podemos melhorar a documentação desses fluxos de trabalho recomendados

A outra dica é que discourse.theme-creator.io é executado com ativos Ember em modo de desenvolvimento. Portanto, isso também deve ter mensagens de erro melhores.