デザインのカスタマイズについては、プラグインではなくテーマを使用することが推奨されていることに気づきました。その利点は何でしょうか。
開発者の視点から見ると、テーマはあまりにも煩雑に感じられます。コードの変更をリアルタイムで確認するために、もう一つのツールが必要になります - テーマ CLI コンソール。
また、テーマはユーザーが選択可能であることも理解しています（私はその機能は必要ありません）。
本番環境において、テーマがプラグインよりも優れている点はどこでしょうか？
「いいね！」 1
私の考え:
- ビルド時ではなく、実行時のインストール時に discretion を提供し、ダウンタイムゼロを実現。
- 無効化や削除が容易。
- コンソールにアクセスできないホスト型クライアントでも利用可能。
ただし、開発者の視点からすれば、プラグインの方が通常、ナビゲーションしやすいと思います。
「いいね！」 4
【テーマの JavaScript を複数のファイルに分割】（https://meta.discourse.org/t/splitting-up-theme-javascript-into-multiple-files/119369）が追加されたことで、テーマを通じてプラグインと同様に Ember を使って「あらゆること」を実行できるようになりました。
したがって、ルートを作成したり、シリアライザーを変更したり、カスタムデータを保存したりする必要がない場合は、テーマだけで目的を達成できる可能性が高いです。
サポートの観点から見たカスタムプラグインの最大の課題は、サイトの停止です。これは通常、プラグインがコアの Rails クラスやメソッドにパッチを当てており、そのクラスやメソッドが変更されたにもかかわらず、プラグインがまだそれに対応するよう更新されていないことが原因です。Ember 側で何らかの変更があり、その結果としてテーマやテーマコンポーネントが破損した場合、サイトが正しくレンダリングされなくなることがありますが、/safe-mode を使用して素早く無効化できます。
ご指摘の通りだと思います。また、その gem を使用すれば、ローカルでテーマを開発し、API キーを持っている任意の Discourse サイト（theme-creator.discourse.org も含む）と同期させることができます。その gem 1 つを実行していれば、ローカルの開発環境をセットアップする必要さえありません。
「いいね！」 10
この記事の返信は素晴らしいですね。私が付け加えることはほとんどありません。
付け加えるべき重要な点として、Discourse 社内部では、現在、いくつかのプラグインを「バックエンド用プラグイン」と「フロントエンド用テーマ」に分割する取り組みを進めています。このように機能が混在する状況における「配布」の課題についても検討しています。
全体的に、私が強く推奨するのは、絶対に必要な場合を除いて、プラグインの作成に頼らないことです。Ruby バックエンドを変更する必要がある場合は、プラグインを使うしかありません。フロントエンドの変更のみを行うプラグインは、強く非推奨です。アップデートの維持が難しく、また利用の柔軟性も著しく低下するためです。
「いいね！」 12