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.

「いいね!」 2

私も興味があります。答えは見つかりましたか?:grinning:

生テンプレートはパフォーマンス最適化です。Ember ビューの機能の一部のみが存在し、機能を削除することで高速化されています。

そのため、拡張性のためにはここで異なるパターンを使用します。完全な Ember ライフサイクルは備わっていません。

「いいね!」 3

raw な outlet に対しても setupComponent(args, component) と似たものはありますか?計算プロパティはどうでしょうか?コンテキスト内のデータに基づいていくつかの計算を行いたいのですが、どのようにすればよいでしょうか。私が作成した付随する .js.es6 ファイルの名前が正しいのかも分かりません。.raw.js.es6 と名付けるべきでしょうか?

SetUpComponent not being called for topic list tags plugin outlet - #3 by net_deamon

解決策が見つかりました:Topic モデルを reopen して、そこで計算プロパティを作成します。

https://github.com/paviliondev/discourse-events/blob/master/assets/javascripts/discourse/initializers/event-edits.js.es6#L74

その後、raw テンプレート内で使用できます。

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

「いいね!」 1

同じ質問があります。

通常のコンポーネントのように、テーマコンポーネント内で、対応する JavaScript を伴う「raw template」をバックアップすることは可能でしょうか。

私はかなり複雑なユースケースを抱えており、トピックリスト内に深く埋め込まれたテンプレートから、コンポーネントチェーンをさかのぼって引数を受け渡すアクションを管理する必要があります。

Discourse ソースには、一見対応する JavaScript コンポーネント要素を持つ複数の .hbr ファイルがあることに気づきました。ただし、以下のように奇妙な点も観察されました。

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

したがって、特定のコンポーネントに対して .hbr と .hbs の両方の形式が存在する事例が複数あるように見えます。

ああ、少なくとも topic-list-item ではここで切り替えが行われているのがわかります:

hbs ファイルの内容:

{{topicListItemContents}}

バックエンドの 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;
        }
      });
    }
  },

巧妙ですね!

つまり、hbs ファイルにはこのような回避策でサポートされない限り、裏側の JavaScript ファイルが存在しないということでしょうか?

「いいね!」 1

はい、その通りだと思います。他に方法があるとしたら、私は見たことがありません!

「いいね!」 1

そのオブザーバーは理想的ではありません。Ember のアップグレードを続けるにつれて、オブザーバーの使用を避けようとしているからです。より良い方法は、ヘルパーを作成して JS をそこに記述することです。以下に例を示します。

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

「いいね!」 2

最近の作業では、テンプレートの「ツリー」の一部が、クローズドアクションを使用して葉テンプレートからデータを親へ伝達できるようにする必要がありました。そのため、これをサポートするために、一部の .hbr ファイルを .hbs ファイルに変更しました。

この作業は実験的なものであり、パフォーマンスに影響を与える可能性があることは理解しています。しかし、設計を数回反復しても、フレームワークの範囲内でこれを達成する代替手段を見つけることができませんでした。

ヘルパーに関数を渡して、そこで呼び出すことはできないのでしょうか?私は試したことがありませんが、可能だと思われます。

「いいね!」 1

具体的には、リーフコンポーネント内で画像のプロパティを決定し、それらを親の親(グランドペアレント)のプロパティとして保存して、現在のリストレンダリングを超えて維持される必要があるスタイリングに影響を与えています。データは確かに上方向に渡す必要があります。もしヘルパーがそれを達成できるのであれば、現在のアプローチで行き詰まった場合に良い選択肢になりそうです。ありがとうございます!

「いいね!」 1