Impossibile mettere il template nell'outlet desiderato

Sviluppatore
1

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.

1 Mi Piace
2

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

2 Mi Piace
3

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

2 Mi Piace
4

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

1 Mi Piace
6

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 :slight_smile:

    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.

6 Mi Piace
7

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

2 Mi Piace
8

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>
4 Mi Piace
9

Grazie. Non è sembrato molto trasparente! :sweat_smile:

3 Mi Piace
10

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

SCR-20241014-kvau
SCR-20241014-kvau1444×214 33.3 KB

SCR-20241014-kvmu
SCR-20241014-kvmu1480×234 32.6 KB

5 Mi Piace
11

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?! :sweat_smile: Ci sono molti di questi esempi.

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

3 Mi Piace
12

Ahi, questo è grave!

Quando provo localmente, vedo:

SCR-20241014-muuf
SCR-20241014-muuf1992×146 30.6 KB

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.

4 Mi Piace
13

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.

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!

image

Lo userò in futuro! :rocket:

Non ho idea del perché pensassi che non fosse possibile :blush: :sweat_smile:

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

2 Mi Piace
14

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.

4 Mi Piace
15

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