Impossibile mettere il template nell'outlet desiderato

[NateDhaliwal]

Sto cercando di inserire un template in uno specifico outlet di plugin nel mio javascripts/discourse/initializers/persistent-banner.gjs.
Codice:

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);
  }
}

Ma l’HTML nel tag <template> non viene visualizzato nella posizione dell’outlet. Infatti, non viene visualizzato affatto. Cosa sto sbagliando?
Link al repository: GitHub - NateDhaliwal/discourse-persistent-banner: A theme component for Discourse that cannot be closed by the user.

[merefield (Robert)]

Non usare un inizializzatore per questo? Usa la cartella dei connettori. Ci sono un sacco di esempi.

[NateDhaliwal]

Il motivo è che ci sono diversi output che possono essere selezionati.
Ho adattato questo codice dal repository di Notification Banner.

[merefield (Robert)]

Ah, capito. Sì, ha senso. Mi scusi, non ero sicuro della sua intenzione funzionale. Avrei dovuto leggere il codice più in dettaglio.

[merefield (Robert)]

Ecco alcune cose per rimetterti in moto:

• questo file ha una parentesi tonda di chiusura mancante alla fine della tua chiamata apiInitializer - semplicemente non funzionerà.

Risolvendo quel problema vedo altri errori.

• banner_plugin_outlet non è dichiarato - hai bisogno di un const qui.

  Lo assegni due volte? non ne hai bisogno due volte, sospetto

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

• Mancano importazioni:

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

• … ma non sono riuscito a far funzionare themeSetting come helper qui. Nessun errore, solo vuoto, quindi prova questo codice invece:

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

• Controlla sempre la console per gli errori.

[NateDhaliwal]

Ho importato htmlSafe e ha funzionato a meraviglia!
Grazie mille!

[david (David Taylor)]

@merefield

Non sono riuscito a far funzionare themeSetting come helper qui. Nessun errore, solo vuoto, quindi prova questo codice invece:

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

Sì, l’helper non funziona (e non è necessario) in gjs. Definire un getter va bene. Ma se vuoi evitarlo, puoi fare riferimento direttamente al “globale” settings dal template:

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

[merefield (Robert)]

Grazie. Non è sembrato molto trasparente!

[david (David Taylor)]

Sì, è giusto. Miglioriamo i messaggi di errore:

DEV: Improve error messages for legacy theme helpers in gjs

[merefield (Robert)]

Grazie. Questo aiuta davvero l’esperienza dello sviluppatore.

Che, come sappiamo, è migliorata drasticamente con .gjs rispetto ai widget.

tuttavia

Ci sono molti errori molto strani che si possono ottenere quando si utilizzano componenti gjs che non rendono molto facile trovare i problemi.

Ad esempio, roviniamo il nome dell’helper:
{{html_safe this.bannerTextContent}}

Porta al classico:

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

(questo accade anche qui con un nome valido se si dimentica l’importazione)

Cosa?! Ci sono molti di questi esempi.

Immagino che questo sia uno svantaggio dell’utilizzo di un framework?

[david (David Taylor)]

Ahi, questo è grave!

Quando provo localmente, vedo:

Dove hai visto l’errore WeakMap? Su un sito di produzione? Se sì… forse questo è uno dei controlli che ember ottimizza fuori dalle build di produzione per migliorare le prestazioni.

Se puoi, consiglierei sempre di sviluppare temi/plugin in un ambiente di sviluppo adeguato: ci sono molti casi come questo in cui l’esperienza sarà migliore.

[merefield (Robert)]

Sì, il sito di produzione utilizza Theme CLI ( che immagino sia uno dei suoi svantaggi, nonostante il suo flusso di lavoro altrimenti eccezionale?)

[quote=“David Taylor, post:12, topic:330650, username:david”]nessuno dei controlli che ember ottimizza nelle build di produzione per migliorare le prestazioni.
[/quote]

Ha perfettamente senso.

@david

Consiglierei sempre di sviluppare temi … contro un ambiente di sviluppo adeguato

Sì, con i plugin è la mia scelta principale, ma con i TC c’è una forte tentazione di sviluppare contro un sito di produzione a causa dell’immediatezza del feedback (se non sempre molto utile!)

Ma mi sono appena reso conto che puoi accedere a localhost con la CLI e funziona.

Quindi, duh!

Lo userò in futuro!

Non ho idea del perché pensassi che non fosse possibile

Come al solito, grazie per il tuo aiuto che mi ha fatto risparmiare molto tempo (in futuro )

[david (David Taylor)]

Sì! Localhost con un theme-cli è il modo in cui cerco di lavorare e quello che consiglio agli altri. Possiamo sicuramente fare di meglio nel documentare questi flussi di lavoro consigliati :occhi:

L’altro suggerimento è che discourse.theme-creator.io viene eseguito con asset Ember in modalità di sviluppo. Quindi dovrebbe avere anche messaggi di errore migliori.