指定の差込口にテンプレートが入らない

[NateDhaliwal]

特定のプラグインのアウトレットにテンプレートを配置しようとしています。javascripts/discourse/initializers/persistent-banner.gjs

コード：

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

しかし、<template> タグ内の HTML がアウトレットの場所に表示されません。実際、まったく表示されません。何が間違っていますか？
リポジトリリンク：GitHub - NateDhaliwal/discourse-persistent-banner: A theme component for Discourse that cannot be closed by the user.

[merefield (Robert)]

イニシャライザーは使用しないでください。コネクタフォルダを使用してください。たくさんの例があります。

[NateDhaliwal]

その理由は、選択できるアウトレットがいくつかあるためです。
このコードはNotification Bannerのリポジトリから適応しました。

[merefield (Robert)]

なるほど、わかりました。はい、理にかなっています。意図が分からず申し訳ありませんでした。もっと詳しくコードを読むべきでした。

[merefield (Robert)]

もう一度やり直すためのヒントをいくつかご紹介します。

• このファイルでは、apiInitializer 呼び出しの最後に閉じ括弧がありません。これでは動作しません。

  その問題を修正すると、さらにエラーが見つかりました。

• banner_plugin_outlet が宣言されていません。ここに const が必要です。

  二重に代入していませんか？おそらく二重に代入する必要はないでしょう

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

• インポートが不足しています。

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

• … しかし、themeSetting をヘルパーとしてここで機能させることができませんでした。エラーはありませんでしたが、何も表示されなかったので、代わりにこのコードを試してください。

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

• 常にコンソールでエラーを確認してください。

[NateDhaliwal]

htmlSafe をインポートしたところ、見事に機能しました。
本当にありがとうございます！

[david (David Taylor)]

@merefield

テーマ設定をヘルパーとしてここで機能させることができませんでした。エラーはありませんでしたが、何も表示されなかったので、代わりにこのコードを試してください。

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

はい、ヘルパーはgjsでは機能しません（そして必要ありません）。ゲッターを定義することは問題ありません。しかし、それを避けたい場合は、テンプレートから直接settingsの「グローバル」を参照できます。

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

[merefield (Robert)]

ありがとうございます。あまり透明ではなかったようです！

[david (David Taylor)]

はい、それは妥当です。エラーメッセージを改善しましょう。

DEV: Improve error messages for legacy theme helpers in gjs

[merefield (Robert)]

ありがとうございます。これは開発者体験に大いに役立ちます。

ご存知の通り、.gjs はウィジェットよりも劇的に改善されました。

しかし

gjs コンポーネントを使用すると、非常に奇妙なエラーがたくさん発生し、問題の特定が容易ではありません。

たとえば、ヘルパー名を間違えてみましょう。
{{html_safe this.bannerTextContent}}

これは古典的なものにつながります。

program.js:100 Uncaught (in promise) TypeError: WeakMap のキーとして無効な値が使用されました
at WeakMap.set (<anonymous>)

（インポートを忘れた場合、有効な名前でもここで発生します）

なんてこった！ これのような例はたくさんあります。

フレームワークを使用することの欠点でしょうか？

[david (David Taylor)]

痛っ、それはひどいですね！

ローカルで試すと、次のように表示されます。

WeakMap エラーはどこで確認しましたか？本番サイトですか？もしそうなら…これは、パフォーマンスを向上させるために ember が本番ビルドから最適化して削除するチェックの 1 つかもしれません。

可能であれば、テーマ/プラグインは適切な開発環境で開発することを常にお勧めします。このような多くのケースで、エクスペリエンスが向上します。

[merefield (Robert)]

はい、プロダクションサイトでTheme CLI（を使用しています。これは、それ以外は素晴らしいワークフローであるにもかかわらず、欠点の一つだと思いますか？)

@david

Emberがパフォーマンスを向上させるために本番ビルドから除外するチェックは何もありません。

それは非常に理にかなっています。

@david

テーマの開発は常に…適切な開発環境に対して行うことをお勧めします。

はい、プラグインの場合はそれが私の定番ですが、TCの場合は、フィードバックの即時性（常に役立つとは限りませんが！）のために、プロダクションサイトに対して開発する誘惑があります。

しかし、今気づきました。CLIでlocalhostに入ることができ、それは機能します。

だから、まあ！

今後それを使用します！

それが可能だと思わなかった理由が全くわかりません

いつものように、あなたの助けに感謝します。多くの時間を節約できました（将来的に :)）。

[david (David Taylor)]

はい！テーマCLIを使ったローカルホストでの作業は、私が普段行っている方法であり、他の人にも推奨している方法です。これらの推奨されるワークフローのドキュメントは、間違いなく改善できます

もう一つのヒントは、discourse.theme-creator.io が開発モードのEmberアセットで動作していることです。そのため、こちらもより良いエラーメッセージが表示されるはずです。