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.

Ich wäre auch daran interessiert. Hast du die Antwort schon gefunden? :grinning:

Rohvorlagen sind eine Leistungsoptimierung. Es existieren nur teilweise Ember-View-Funktionen; die Entfernung von Funktionen ist es, die sie schneller macht.

Daher verwenden wir hier ein anderes Muster für Erweiterbarkeit. Wir haben nicht den vollständigen Ember-Lebenszyklus.

Gibt es etwas Ähnliches wie setupComponent(args, component) auch für die rohen Outlets? Was ist mit berechneten Eigenschaften? Ich möchte einige Berechnungen basierend auf den Daten im Kontext durchführen. Wie gehe ich dabei vor? Ich weiß nicht einmal, ob ich meine begleitende .js.es6-Datei richtig benannt habe. Sollte sie .raw.js.es6 heißen?

Okay, ich habe die Lösung gefunden: Das Topic-Modell erweitern und dort eine berechnete Eigenschaft erstellen:

https://github.com/paviliondev/discourse-events/blob/master/assets/javascripts/discourse/initializers/event-edits.js.es6#L74
Anschließend kann sie in der rohen Vorlage verwendet werden:

https://github.com/paviliondev/discourse-events/blob/master/assets/javascripts/discourse/connectors/topic-list-after-title/topic-list-event-rsvp.raw.hbs#L5

Ich habe dieselbe Frage.

Ist es möglich, eine rohe Vorlage innerhalb einer Theme-Komponente mit entsprechendem JavaScript wie bei regulären Komponenten zu versehen?

Ich habe ein ziemlich herausforderndes Anwendungsszenario und muss Aktionen verwalten, um Argumente von einer tief eingebetteten Vorlage innerhalb der Themenliste zurück an die übergeordnete Komponentenkette weiterzuleiten.

Ich habe festgestellt, dass es mehrere .hbr-Dateien mit scheinbar entsprechenden JavaScript-Komponentenelementen im Discourse-Quellcode gibt, aber mir ist etwas Auffälliges aufgefallen, z. B.:

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

Es scheint also mehrere Fälle zu geben, in denen es .hbr- und .hbs-Varianten einer bestimmten Komponente gibt?

Ah, zumindest bei topic-list-item sehe ich, dass hier der Wechsel stattfindet:

Inhalt der hbs-Datei:

{{topicListItemContents}}

Zugehöriges JavaScript:

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

Heuchlerisch!

Das legt also nahe, dass hbs-Dateien keine zugrunde liegenden JavaScript-Dateien haben, es sei denn, sie werden durch eine solche Workaround-Technik unterstützt?

Ja, das ist meiner Meinung nach der Fall. Wenn es noch eine andere Möglichkeit gibt, habe ich sie noch nicht gesehen!

Dieser Observer ist nicht ideal, da wir im Rahmen der weiteren Verbesserungen von Ember versuchen, solche Observer zu vermeiden. Ich denke, ein besserer Ansatz besteht darin, einen Helper zu erstellen und den JavaScript-Code dort unterzubringen. Hier ist ein Beispiel:

https://github.com/discourse/discourse-category-experts/blob/main/assets/javascripts/discourse/connectors/topic-list-after-title/category-experts-indicator.hbr

In einigen neueren Arbeiten musste ich dafür sorgen, dass Teile des Template-“Baums” Daten von einem Blatt-Template nach oben weitergeben können, indem ich Schließungsaktionen verwende. Daher habe ich einige hbr-Dateien in hbs-Dateien umgewandelt, um dies zu unterstützen.

Die Arbeit ist experimentell, und ich bin mir bewusst, dass dies Auswirkungen auf die Leistung haben wird. Nach mehreren Iterationen des Designs konnte ich jedoch keine alternative Lösung finden, die innerhalb des Frameworks bleibt.

Kann man Funktionen nicht an einen Helper übergeben und dort aufrufen? Ich glaube nicht, dass ich das schon versucht habe, aber ich stelle mir vor, dass das möglich ist.

Spezifisch bestimme ich Eigenschaften eines Bildes in einer Leaf-Komponente und speichere sie dann als Eigenschaften des Großeltern-Elements, um ein Styling zu beeinflussen, das über das aktuelle Listen-Rendering hinaus bestehen bleiben muss. Die Daten müssen definitiv nach oben weitergegeben werden. Wenn ein Helper dies erreichen kann, klingt das nach einer guten Option, falls ich mit meinem aktuellen Ansatz nicht weiterkomme. Danke!