移行のコストを軽減する1つの方法は、コンポーネントの呼び出し元から渡された静的文字列に対応する引数をアドオンが静的に示すことができるようにすることです。

スピットボールとして（ better-componentは静的コンポーネントキーワードの名前のプレースホルダーです）。

{{better-component <strong i="8">@arg</strong> staticString=true}}

これにより、アドオンは、特定の「動的呼び出し」が、呼び出し元が静的文字列を提供した場合にのみ機能することを示すことができます。

これを行う必要があるのは、実際には、多くの動的コンポーネントのケースが、単純な「アドオンに渡される文字列引数」によって引き起こされている場合のみです。

これがこの問題のトピックである場合はIdkですが、私は定期的にemberclearで完全な静的性を把握しようとしており、問題とその解決策の紙の証跡を保持しています。

https://github.com/NullVoxPopuli/emberclear/pull/784

それで、人々が問題に遭遇した場合、おそらく阿部のドキュメントが役立つでしょうか？ Idk

また、私は刺繡にとても興奮していて、完全な静的性が達成されたらすでに大きな計画を持っています
https://github.com/emberjs/rfcs/issues/611

私たちのアプリケーションは動的コンテンツ配信システムです。 コンテンツ作成者は、「アクティビティ要素」からコンテンツを組み立てます。各要素には、対応するEmberコンポーネントがあり、その名前はEmberデータモデルで定義されています。 このシステムの心臓部は多かれ少なかれ次のようになります。

// example model definition
export default class TextElement extends Model {
  _componentName = 'text-element';
}

  {{#each (sort-by "position" @activityElements) as |activityElement|}}
    {{component (get activityElement "_componentName")}}

上記を読んだところ、これは(component dynamicString)シナリオであることがわかりました。 それは正確ですか？

上記を読んだことは、これが（コンポーネントdynamicString）シナリオであることを示唆しています。 それは正確ですか？

@activityElementsとは何ですか？どこで定義されていますか？

これは、コントローラーコンポーネントに渡されるEmberデータモデルインスタンスの配列になります。

また、動的コンポーネント、FYIにも少し多額の投資を行いました。 私は昨年ここでそれについて尋ねました： https ：

私たちもそうします。 私たちは文字通り、アプリで使用されるコンポーネントを事前に知りません。 それらはデータベースに格納され（もちろん変更可能になります）、バックエンドでコンパイルされ、オンデマンドでフロントエンドに送信されます。 動的なcomponentヘルパーを使用できないことは、配列全体で使用できないことと同じです。 このようなユースケースに何らかの前進があることを心から願っています。 必要なダイナミズムがないためにアプリが機能しない場合は、コードの分割やツリーの揺れは絶対に気にしません。

そのシナリオで有効なすべてのコンポーネントのマップを使用できますか？

例えば：

{{#let (hash
   Foo=(import 'path/to/foo')
   Etc=...
) as |validComponents|
}}
  {{component (get validComponents @someDynamicValue)}}
{{/let}}

？

同様に、アプリ内にあるものしかレンダリングできないため、完全な動的コンポーネントを実際に作成することはできません。レンダリングするものを選択するリストを作成すると、デバッグにも役立ちます。 「ああ、この値は有効なコンポーネントの1つではありませんでした」

そのシナリオで有効なすべてのコンポーネントのマップを使用できますか？

これは間違いなく私たちのユースケースをカバーします。

@NullVoxPopuli @jherdman素晴らしい！

一般に、 (component dynamicString)代わりに人々が何をする必要があるかを考える方法は、どこかに行くためにimportまたは(component "staticString")が必要であるということです。

オプションは次のとおりです。

• コンポーネントの呼び出し元は(component "staticString")
• ダイナミズムを備えたコードは、可能性を列挙し、それらをマップに配置し、 (get componentMap dynamicString)を使用してそれらを取り出します。

今、あなたは考えているかもしれません： (get components dynamicString)が(component dynamicString)よりも優れているのはなぜですか？ 答えは、 componentMapをどこかに構築する必要があり、ルールは再帰的に適用されるということです。

したがって、 <InputField @type="text" />または<InputField @type="checkbox" /> （HTMLの<input> ）を記述できるコンポーネントを記述しているとします。

input-fieldテンプレートは、次のようになります。

{{#let (hash text=(component "inputs/text-field") checkbox=(component "inputs/checkbox")) as |components|}}
  {{component (get components @type)}}
{{/let}}

この方法でコードを作成すると、Embroiderは、バンドルに2つのコンポーネントを含めるだけでよいことがわかります。 あなたはそれをこのように書いていましたか？

{{component (concat "inputs/" <strong i="33">@type</strong> "-field")}}

（はい、そのようなことは驚くほど一般的です）

その場合、Embroiderはコードを簡単に分析できず、バンドルに含まれるコンポーネントを制限できません。 JavaScriptで作業を行った場合、これはさらに悪化します（これも非常に一般的です）。

export default class extends Component {
  get innerComponent() {
    return `inputs/${this.args.type}-field`;
  }
}

このテンプレートを使用して：

{{component this.innerComponent}}

これは小さな調整ですが、Embroiderが実際に使用されているコンポーネントを判別できるようにします。

また、他の2つの実行中の機能への接続をより注意深く説明したいと思います。

1. テンプレートのインポート
2. コンポーネントクラスを呼び出し可能オブジェクトとして使用する

これらの2つの機能を使用して前の例を書き直すと、次のようになります。

---
import TextField from "./text-field";
import Checkbox from "./checkbox";
---
{{#let (hash text=TextField checkbox=Checkbox) as |components|}}
  {{component (get components @type)}}
{{/let}}

これには、Embroiderが理解する必要のある特別なルールを排除し、モジュールに関するコード分割のユーザーモデルをさらに作成するという優れた特性があります。

コンポーネントクラスを呼び出し可能オブジェクトとして使用する

RFC＃481以降、コンポーネントクラスは完全に自己完結型のユニットであり、GlimmerVMがコンポーネントとして呼び出すために必要なすべての情報を備えています。

注：これは、 @ember/componentまたは@glimmer/componentから継承するクラスだけに当てはまるわけではありません。 RFC 481以降、Emberの「コンポーネント」の定義は「テンプレートとコンポーネントマネージャーに関連付けられたオブジェクト」であり、フックされたコンポーネントなどのカスタムコンポーネントが含まれてい

RFC＃432 （コンテキストヘルパーおよび修飾子）およびRFC＃496 （ハンドルバーの厳密モード）以降、Emberのテンプレート構文の将来の設計は次のとおりです。ヘルパー、コンポーネント、または修飾子を含む式は、ヘルパー、コンポーネント、または修飾子として呼び出すことができます。

承認されたRFCの現在のコレクションの意味するところは、 <SomeComponentClass /> （またはthis.componentClassがコンポーネントクラスに解決される場合は<this.componentClass> ）が「正しく機能する」ということです。 これは、実装作業の記録計画でもあります。

とはいえ、わかりやすくするために、この動作を明示的に指定する新しいRFCを作成する必要があります。

HBSの有効なコンポーネントのリストをどこかに指定することは可能ですが、注意が必要な点がいくつかあります。

1. 現在、 @ wycatsが指摘したJSソリューションを使用しています。 HBSプロバイダーで同じことを行うことは可能ですが、私たち全員が知っているように、HBSのロジックは少し難しいです。 また、プロバイダーコンポーネントが適切なコンポーネントを生成することをユニットテストすることは、適切な文字列を返すutil関数よりもはるかに困難です。

2. これはJS（とにかくパブリックAPIを使用）afaikには存在しませんが、ディレクトリ構造を使用すると非常に便利です。 例えば：

   {{#let (lookup-directory "components/inputs/") as |components|}}
   {{/let}}
   

   この種のことは、ディレクトリ構造によってグループ化されたポリモーフィックタイプがわかっている場合、時間の経過とともに保守しやすくなる可能性があります。

いずれにせよ、動的コンポーネントは、これを引き継ぐのではなく、議論するために独自の問題が必要だと感じています🙈😄

いずれにせよ、動的コンポーネントは、これを引き継ぐのではなく、議論するために独自の問題が必要だと感じています🙈😄

私は同意し、RFCリポジトリでまもなく開き、ここにリンクを投稿します。

@mehulkar @wycats @jherdmanユーザーが動的に呼び出し可能なコンポーネントのリストをインポートできるようにするのはどうですか？ 追加レベルの間接参照を含むヘルパーよりもはるかに簡単にフォローできるようです。

import Component1 from './dynamic/component-1';
import Component2 from './dynamic/component-2';
import Component3 from './dynamic/component-3';

export default class extends Component {
  get innerComponent() {
    switch(this.args.type) {
      case 'one':
        return Component1;
      case 'two':
        return Component2;
      case 'three':
        return Component3;
      default:
        // handle invalid type
    }
  }
}

次に、テンプレートは次のことを実行できます： {{#let (component this.innerComponent) as |DynamicComponent|}}または同様のもの。

検索/読み取り/分析が簡単で、これらのコンポーネントが使用されている場所を簡単に検出できる、このようなものがはるかに望ましいです。 考え？

@Samsiniteええそれがアイデアだと思います。 HBSのヘルパーは主にシンタックスシュガーであり、テンプレートのみのコンポーネントに役立ちます。

@Samsiniteは基本的に、（テンプレートをインポートする前に）短期的な修正として提案したものです。

コンポーネントクラスを呼び出し可能にする必要があります。これは、このコメントで話していたものです。

行きましょう！

ああ、それはテンプレートのみのコンポーネントには意味があります、誤解してすみません:)。 また、次のテンプレートのみのコンポーネントの構文も気に入っています。

---
import TextField from "./text-field";
import Checkbox from "./checkbox";
---
{{#let (hash text=TextField checkbox=Checkbox) as |components|}}
  {{component (get components @type)}}
{{/let}}

同様に、実際には、チームの他のメンバーが読みやすいと思うものに応じて、おそらくテンプレートのみとjsでバックアップされたコンポーネントに使用します。