What is the difference between raw.hbs handlerbar files and only .hbs handlerbar files?

I noticied that few plugin outlet like topic-list-after-title require raw.hbs file
while other require only hbs file.

I did search in the handlebars documentation, but I could see anything as raw hbs file.

I checked in the discourse code, plugin outlet like topic-list-after-title are defined as

{{raw-plugin-outlet name="topic-list-after-title"}}

while other plugins are defined as

{{plugin-outlet name="composer-fields-below" args=(hash model=model)}}

Q1. Is there any reason why some plugin plugin are defined in above way ( raw-plugin-outlet) ?

Also I noticied that in the raw.hbs file, the setupcomponent is not called as explained in this link

Q2. Is it so? I had also asked similar question regarding this.

I would be interested in this as well. Did you find the answer yet? :grinning:

Raw templates are a performance optimisation. Only partial ember view features exists, removal of features is what makes it faster.

Hence we use a different pattern here for extensibility. We don’t have the full ember lifecycle.

Is there something similar to setupComponent(args, component) with the raw outlets as well? What about computed properties? I would like to do some computations based on the data in context. How can I go about this? I dont even know if I named my accompanying .js.es6 file right. Should I name it .raw.js.es6?

SetUpComponent not being called for topic list tags plugin outlet - #3 by net_deamon
Okay I found the solution: reopen the Topic model and create a computed property there:

https://github.com/paviliondev/discourse-events/blob/master/assets/javascripts/discourse/initializers/event-edits.js.es6#L74
Afterwards it can be used int the raw template:
https://github.com/paviliondev/discourse-events/blob/master/assets/javascripts/discourse/connectors/topic-list-after-title/topic-list-event-rsvp.raw.hbs#L5

Ho la stessa domanda.

È possibile associare a un template raw il corrispondente JavaScript, come avviene per i Componenti normali, all’interno di un Componente di Tema?

Ho un caso d’uso piuttosto complesso e devo gestire le azioni per passare argomenti indietro lungo la catena dei componenti, partendo da un template profondamente annidato all’interno dell’elenco dei topic.

Ho notato che ci sono diversi file .hbr con apparentemente corrispondenti elementi Componente JavaScript nel codice sorgente di Discourse, ma ho osservato qualcosa di strano, ad esempio:

merefield@development:~/discourse$ find . -type f -name "flat-button.*"
./app/assets/javascripts/discourse/app/templates/flat-button.hbr
./app/assets/javascripts/discourse/app/templates/components/flat-button.hbs
./app/assets/javascripts/discourse/app/components/flat-button.js
merefield@development:~/discourse$ find . -type f -name "topic-list-item.*"
./app/assets/javascripts/discourse/app/templates/mobile/list/topic-list-item.hbr
./app/assets/javascripts/discourse/app/templates/components/topic-list-item.hbs
./app/assets/javascripts/discourse/app/templates/list/topic-list-item.hbr
./app/assets/javascripts/discourse/app/components/topic-list-item.js
merefield@development:~/discourse$ find . -type f -name "topic-post-badges.*"
./app/assets/javascripts/discourse/app/templates/components/topic-post-badges.hbs
./app/assets/javascripts/discourse/app/templates/topic-post-badges.hbr
./app/assets/javascripts/discourse/app/components/topic-post-badges.js

Sembra quindi esserci diverse istanze in cui esistono varianti .hbr e .hbs di uno stesso Componente?

Ah, almeno con topic-list-item vedo che lo switch viene fatto qui:

Contenuto del file hbs:

{{topicListItemContents}}

Javascript di supporto:

  @observes("topic.pinned")
  renderTopicListItem() {
    const template = findRawTemplate("list/topic-list-item");
    if (template) {
      this.set(
        "topicListItemContents",
        template(this, RUNTIME_OPTIONS).htmlSafe()
      );
      schedule("afterRender", () => {
        if (this.selected && this.selected.includes(this.topic)) {
          this.element.querySelector("input.bulk-select").checked = true;
        }
      });
    }
  },

Subdolo!

Quindi questo suggerisce che i file hbs non hanno file javascript sottostanti, a meno che non siano supportati da questo tipo di soluzione alternativa?

Sì, credo che sia così. Se esiste un altro modo, non l’ho mai visto!

Quell’observer non è ideale, dato che stiamo cercando di allontanarcene mentre continuiamo a migliorare Ember. Penso che un approccio migliore sia creare un helper e inserire lì il tuo JS. Ecco un esempio
https://github.com/discourse/discourse-category-experts/blob/main/assets/javascripts/discourse/connectors/topic-list-after-title/category-experts-indicator.hbr

In alcuni lavori recenti, ho avuto bisogno che parte dell’albero dei template potesse comunicare dati da un template foglia verso l’alto utilizzando le closure actions, quindi ho convertito alcuni file .hbr in .hbs per supportare questa funzionalità.

Il lavoro è sperimentale e so che avrà un impatto sulle prestazioni, ma dopo aver iterato più volte sul design non sono riuscito a trovare un’alternativa per farlo mantenendo tutto “all’interno del framework”.

Non puoi passare funzioni a un helper e chiamarle lĂŹ? Non credo di averlo mai provato, ma immagino sia possibile farlo.

Nello specifico, sto determinando le proprietà di un’immagine in un componente foglia, per poi memorizzarle come proprietà del componente genitore per influenzare lo stile che deve persistere oltre il rendering corrente dell’elenco. I dati devono assolutamente essere passati verso l’alto. Se un helper può raggiungere questo obiettivo, sembra un’ottima opzione nel caso in cui mi trovassi in difficoltà con l’approccio attuale, grazie!