コンポーネントAPI全体が利用可能であることの柔軟性に感謝しています。全体的にGlimmerコンポーネントの構文は気に入っており、コードベース内の複雑さを軽減するのに役立つ理由も理解できます。
しかし、基本的なユースケース（ボタンを追加してアイコンを付けたい場合）では、古いAPIメソッドの方が客観的に簡潔で理解しやすかった（インポートが少なく、操作が少なく、公開されるAPIフットプリントが少ない）です。古いAPIメソッドが引き続きサポートされない理由はあるのでしょうか？それらを便利な関数として使用し、基盤となる実装を新しいGlimmerコンポーネントで行うことで、APIメソッドもバージョン互換性のチェックを実行できると想像しています。
これにより、これらのメソッドを使用しているユーザーへの影響ははるかに少なくなり、プラグインエコシステム内の条件付きロジックのコード爆発も少なくなります。
既存のウィジェットに関する主な不満は、ドキュメントの不足です。それらの削除を発表するこの投稿は、これらの特定のメソッドが存在し、それらをどのように使用するかについての、私がこれまで見た中で最も明確なドキュメントの1つです。実際、古いAPIの使用方法を理解しようとしてここにたどり着きました。
トランスフォーマーが文字列リテラルで一元登録されているのは良いと思います。これにより、ドキュメント（およびプラグイン開発）の作業が大幅に楽になります。
ウィジェットでは、すべてcreateWidgetメソッドで登録され、その後createWidgetFromが呼び出されるようです。これに関する問題は、レジストリがAPIによって保護されたファイルスコープのグローバル変数であり、APIは反復処理を許可しないことです。ウィジェットレジストリに反復関数があれば、現在登録されているウィジェットをリアルタイムで検出できます。「ブラウザコンソールでこのJavaScript行を実行してAPIを呼び出し、レジストリを一覧表示する」と文書化されるべきです。そうすれば、トランスフォーマーレジストリが提供するものと非常に似たユーティリティを得ることができます。
プラグイン開発に役立つもう1つのことは、コンポーネント/ウィジェットによってレンダリングされたルートDOM要素に、どのコンポーネント/ウィジェットであるかを示す属性があることです。「data-widget=foo」のようなものです。これはデバッグ機能になることも、デフォルトで有効になることもあります。OSSなので、隠蔽によってセキュリティを確保しているわけではありません。
Glimmerコンポーネントへの移行を歓迎します。しかし、これには時間がかかり、その間、人々が対応する必要のあるウィジェットがたくさんあります。したがって、上記で述べたウィジェットの可視性を向上させることが、移行期間をすべての人にとってより容易にするだろうと思います。
APIメソッドについては…詳細なコメントをJavaScript APIに追加する手間をかけたようですが、ドキュメントサイトは生成されませんでした。なぜですか？
もしよろしければ、ウィジェットレジストリの反復処理のためのプルリクエストを提出したいと思います。