pfaffman
2022 年 1 月 3 日午後 8:42
1
Splitting up theme Javascript into multiple files からの議論の続きです。
以前、テーマでの開発とプラグインでの開発について議論がありました。https://www.pfaffmanager.com/ の Rails 部分はかなり安定してきており、Rails 部分の開発をテーマコンポーネントに移行したいと考えています。これはうまくいっており、テーマコンポーネント内のテンプレートやイニシャライザの変更は、プラグインのものを期待通りにオーバーライドしています。**しかし、**テーマ内の javascripts/discourse/components/server-item.js.es6 への変更は、プラグイン内の同じファイルをオーバーライドしていません。
プラグインから Ember の部分を完全に削除し、テーマにのみ存在させることもできますが、それらのピースをすべて移動、テスト、サーバーにプッシュするには 1 日仕事になりそうです。何か単純なことを見落としているのでしょうか？テーマコンポーネントに含めたいものをプラグインから完全に削除すべきでしょうか？それともすべてプラグインに入れておくべきでしょうか？
david
2022 年 1 月 4 日午前 10:55
2
テーマコンポーネントとプラグインの両方に同じコードが含まれているのは少し奇妙だと思います。IMOでは、テーマコンポーネント/プラグインのいずれかを選択し、すべてを投入するのが良いでしょう。ファイル全体をオーバーライドすることは、私たち自身が行うことでもなく、推奨することでもありません。コア/プラグインの動作をオーバーライドするには、テーマコンポーネントで api.modifyClass のようなメソッドを使用する必要があります。
根本原因は、プラグインのES6モジュールがコア/テーマモジュールとは異なるプレフィックスが付いていることだと思います。サイトでこれを実行すると、モジュールには plugin というプレフィックスが付いていることがわかります。テーマコンポーネントを有効にすると、別のエントリが表示されると思いますが、プレフィックスが異なります。
「いいね！」 1
pfaffman
2022 年 1 月 5 日午後 2:32
3
まあ、Ember全体がまだ奇妙に思えます。
クール。すべてのJavaScriptを含む単一のプラグインを使用します。
そして、そのObject.keysのマジックは非常にクールで、私は決してそれを理解できなかったでしょう。それについてはいくら感謝してもしきれません。そして、あなたは正しいです：
(4) ['discourse/plugins/Pfaffmanager/discourse/components/compact-server-item',
'discourse/plugins/Pfaffmanager/discourse/components/server-item',
'discourse/theme-11/components/server-item',
'discourse/theme-11/components/compact-server-item']
「いいね！」 1
一般的には同意しますが、いくつか例外的なケースがあります。
JavaScriptの変更量がバックエンドの変更量をはるかに上回る場合。このような場合、テーマコンポーネントはコードを迅速に展開およびテスト展開するための優れた方法となります。
ほとんどの機能がベースのテーマコンポーネントで提供できるが、補完的なプラグインを追加することで、JavaScriptだけでは不可能な追加機能を実現できる場合。私はトピックリストプレビューでこの手法を採用しています。コンポーネントはアドオンが可能なことの90%を実行しますが、プラグインも追加すると、さらにクールな機能が得られます。
とはいえ、すべてをプラグインにパッケージ化することは、設定とインストールの混乱が少なく、常にすべてが同期しているため理にかなっています。
「いいね！」 3
pfaffman
2022 年 1 月 5 日午後 3:28
5
しかし、プラグインとテーマのシナリオであっても、Emberのコードをプラグインとテーマの両方に重複させることはしません。したがって、テンプレート、イニシャライザ、コンポーネントの少なくともほとんどをプラグインから引き出し、それらをテーマコンポーネントにのみ配置する必要があります。
設定について混乱するのは私だけなので、それは大きな問題ではありません。テーマのベータ版に切り替えることで、ライブサイトで新しいフロントエンドのものをテストできるというアイデアは本当に気に入っています。
「いいね！」 2
david
2022 年 1 月 5 日午後 3:29
6
サーバーサイドのものをプラグインに、クライアントサイドのものをテーマに含めるのは理にかなっています。私たちもそうしています
私の反対意見は、同じ JavaScript ファイルをテーマとプラグインに同時に定義することでした。
「いいね！」 2
pfaffman
2022 年 1 月 5 日午後 4:26
8
この件についてご協力いただきありがとうございます。
もう一つ、qunitテストを実行する際に問題が発生しています。(テストを追加する方法はここでは省略しますが、それはそれとして別の問題です。表示するデータでテストをシードする方法がわからないのだと思います…)。プラグインにqunitテストがあれば、githubにプッシュしたときに実行されると思います（壊れたテストが失敗するのを見たことがあるので）。
テーマコンポーネントでも同様のことを行うことはできますか？
「いいね！」 1
david
2022 年 1 月 5 日午後 4:38
9
技術的には可能であるはずですが、テーマ用のすぐに使える GitHub Actions ワークフローはまだないと思います。現在、テーマのテストは（ember-cli への移行のために）大幅に変更されていますが、その後、GitHub - discourse/.github にテーマテストワークフローのテンプレートを追加できるかもしれません。
「いいね！」 2
テンプレートにも当てはまりますか？
シナリオ：プラグインにデプロイされたテンプレートをオーバーライドしたい。しかし、コードで制御された方法でオーバーライドしたい。
そのため、新しいテンプレートをテーマコンポーネントに出荷しようとしました。同じファイルがプラグインにも存在しますが（ただし異なります）。
これは私の開発クラウドインストールでは機能するようですが、標準のプロダクションインストールでは機能しません。
したがって、テンプレートでこれが成功するかどうか予測できないと言っても公平ですか？つまり、アセットパイプラインは、定義済みの予測可能な優先順位がないため、どの「テンプレート」が有効になるかを予測できないということですか？
私は次のような階層に関するいくつかの奇妙な仮定で作業していました。
コア
プラグイン
テーマコンポーネント
ローカルサイトの変更
そして、その階層の後のレベルに同じパスと名前の「ファイル」を配置した場合、それは「以前の」定義をオーバーライドすることになります。
しかし、私の仮定は安全ではないかもしれませんか？
唯一の「パッケージ化された」ソリューション（ローカルサイトの変更を除く）は、プラグインをフォークして、変更を直接その中に行うことでしょうか？
それはある意味残念でしょう。カスタム化のメンテナンス作業が増加するため、メインのプラグインリポジトリへの変更を定期的にマージする必要があるからです…
david
2022 年 10 月 10 日午前 9:09
11
既存のプラグインを更新し、テーマコンポーネントが使用できるプラグインのアウトレットやカスタムAPIを提供するのが最善の方法です。
上記の私のコメントは、特にJavaScriptファイルをオーバーライドすること（つまり、es6モジュール）についてでした。それは不可能です。アセットパイプラインは、プラグイン/テーマモジュールにプラグイン/テーマ名/IDを自動的にプレフィックスとして付けるため、コアとの競合を作成することは不可能です。
テンプレートについては、人々（状況によっては私たちも）がオーバーライドすることを知っているので、そのシステムは引き続き機能する可能性が高いです。しかし、それはハック であることを忘れないでください。元のコンポーネント/コントローラーの動作が変更された場合、オーバーライドされたテンプレートはおそらくサイトを壊すでしょう。
一般的に、あなたが言及した階層（コア、プラグイン、テーマ）が真実であるべきだと思います。もし異なるものを見ている場合は、プラグインとテーマのファイルパスの詳細を共有してください。
「いいね！」 3
merefield
2022 年 10 月 10 日午後 2:15
12
ご確認ありがとうございます。実際には、問題はそれとは関係ありませんでしたが、明確化のおかげで正しい場所を確認することができました！
「いいね！」 2
