David、“split"コンポーネントと”.gjs"でないもののサポートを終了する予定はありますか？
おそらくそうでしょう。当面はEmberで個別のjs/hbsがサポートされるようですが、テーマ/プラグインのビルドシステムを簡素化するために、より早く移行することが理にかなっているかもしれません。
hbsを非推奨にする場合、通常の非推奨サイクルとアナウンスメントを経て進めますので、突然の出来事にはなりません。
標準のリンティング設定を使用しているテーマ/プラグインでは、すでに.hbsファイルは禁止されており、gjsへの移行を支援する自動ツールがあります。CDCK所有のテーマ/プラグインは、そのツールでほぼ更新が完了しています。
「いいね！」 5
確認のため（js/hbsコンポーネントを編集できるように）、hbsコンポーネントはテーマのスケルトンではサポートされておらず、gjsへの移行が強く推奨されているということでよろしいでしょうか？
Hbsファイルは引き続き「サポート」されます（つまり、動作し、非推奨期間なしに変更することはありません）。
ただし、新しいコードには.gjsを使用し、既存のテーマとプラグインの移行を開始することを強くお勧めします。スケルトンの最新のlint設定では、意図的にルールをオプトアウトしない限り、その推奨事項が適用されます。
「いいね！」 3
ああ、今わかりました。説明してくれてありがとう！
「いいね！」 2
いずれにせよ、Glimmerコンポーネントは3〜5倍高速になる可能性があると考えているので、間違いなく良い習慣でしょうか？
「いいね！」 3
Glimmerコンポーネントは従来のコンポーネントよりも大幅に高速です、はい！
ただし、.gjsファイル形式が必ずしもglimmerコンポーネントであることを意味するわけではありません。コアにはまだ数百の従来のコンポーネントがあり、それらはすべて.gjsファイル形式に変換されています。（名前が紛らわしいのは承知しています:sweat_smile:）
実行しているcodemodは、js / hbs → .gjsのファイル形式変換のみを行います。コンポーネントタイプは変更しません。完全に自動化することはほぼ不可能です。
「いいね！」 4
もっともですが、手動でのリファクタリングの途中の場合、努力する価値はしばしばあります。
「いいね！」 3
OMG。理解し始めたと思った矢先に。
私だけじゃなかったんですね！ 
これは Glimmer コンポーネントになるのでしょうか？
そして、もしそうなら、テンプレートであっても、クラスを追加すると、単に <template>私の重要な言葉</template> を持つ .gjs よりも速く実行されるのでしょうか？
export default class MyCoolComponent extends Component {
「いいね！」 1
それはこれです:
import Component from "@glimmer/component";
(および、その後の Glimmer の規範への準拠。
「いいね！」 2
なるほど！インポートされたコンポーネント部分を使用するには、クラスを宣言する必要があるということですね。
どうもありがとうございました！
「いいね！」 3
ここでの私の主な問題は、hbsでは明示的なインポートを必要としないため、別のテーマコンポーネントからコンポーネントを簡単に参照できることです。しかし、gjsではそれをimportする必要があり、別のテーマコンポーネントで定義されたコンポーネントをどのように参照すればよいのかわかりません。
私が見てきた既存の実装は、a）まだhbsを使用しているか、b）JavaScriptベースのインジェクションを使用しています。
「いいね！」 1
その場合、この eslint の推奨事項が表示されます。
これは、必要がない限りクラスを追加すべきではないことを示唆しています。そうしないと、実際には遅くなるからです。
「いいね！」 1
パフォーマンスの昇順で：
-
クラシックコンポーネント：
import Component from "@ember/component"; export default class Blah extends Component { -
グリマーコンポーネント：
import Component from "@glimmer/component"; export default class Blah extends Component { -
テンプレート専用グリマーコンポーネント：
export default <template> ... </template>
その通りです
テーマは現在、他のテーマからインポートすることはできません。名前ベースの解決によるテーマ間の依存関係が可能だったという事実は、実際には意図したものではありませんでした 
ユースケースについて、おそらく別のトピックで詳しく説明していただけますか？まだ、私たちが自身のテーマで見つけたものではありません。
「いいね！」 3
それがあると思います…（右サイドバーブロック）。
先週、私の主なユースケースは、同じプラグインアウトレットを使用する複数のテーマコンポーネントの順序を強制することでした。CSSファイルはアルファベット順にロードされますが、テーマコンポーネントのJSは数値順にロードされるため、テーマコンポーネントを削除し、必要な順序で再度追加し、同時に発生するすべてのCSSの問題を回避しようとしました。
その後、それらのそれぞれからコネクタを削除し、そのプラグインアウトレットに対して単一のコネクタにこれを持つ新しいテーマコンポーネントを作成できることに気づきました。
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
これは非常にうまく機能します。そして、私は「ああ、数か月後にこれをやり直す必要を避けるために、これを gjs にする必要がある」と思いました。そして 
「いいね！」 1
お客様があなたに移行する際に、これをやりたいと考えていたお客様がいました。詳細は覚えていません。
最近立ち上げたお客様のために、これをフォークしました。彼らは他の種類のブロックをいくつか追加したいと考えていました。CSSだけを行う姉妹テーマを試しましたが、最終的には諦めてフォークしなければなりませんでした。他に方法があったかどうかはよくわかりません。
「いいね！」 1
しかし…
「いいね！」 2
それは素晴らしいニュースです。もっと早く理解していればよかったのですが。それを見た覚えも、その問題について議論した覚えもあり、誰かにフォークする必要があると言われた覚えもありますが、今はそうする必要はないと確信しています。
Hmmm… Discourse Bars 🍻 🍸 (a sidebar framework) …は同じシステムを使用しており、問題はありませんでした。
これの全体的なポイントは、他のテーマコンポーネントまたはプラグインからコンポーネントを使用できることです（そしてそれは機能します）。
right-sidebar-blocks と discourse-tc-bars はどちらも Ember リゾルバを使用して名前でコンポーネントを検索しています。現時点ではこれは機能しており、非推奨ではありません。
.hbs では {{component \"some-name\"}} のように行われ、(g)js では resolveRegistration(\"component:some-name\") のように行われます。
しかし、長期的なことを考えると、Ember リゾルバでコンポーネントを検索することは避けるべきです。最終的に Embroider の「静的呼び出し可能」フラグを有効にすると、リゾルバは空になります。
これが、right-sidebar-blocks およびその他の同様のテーマ/プラグイン間のコンポーネント共有で取るべき方向性だと思います。
「いいね！」 5