これは、現在のように、テーマコンポーネントに依存しない一般的な方法で行う必要があると思います。
この手法を使用する別のテーマコンポーネントがあります。
これは私の側からの少なくとも2つであり、さらに増える可能性があります。
「いいね！」 3
同意します。パッケージにバンドルするのではなく、それぞれが独立したブロックコンポーネントのコレクションを構築しました: https://gitlab.com/manuelkostka/discourse/blocks。
現在、Homepage Blocks コンポーネントを使用してこれらのブロックを専用のホームページに配置できます。Right Sidebar Blocks や Bars で使用することもできます。
最近、カスタムサイドバーレイアウトが必要な Central テーマで実験を行いました。カスタムサイドバー用のブロックフレームワークを簡単に構築し、そこにブロックコンポーネントを配置できました: https://central.kostka.studio (また、Powered-by-discourse コンポーネントを名前で参照するだけでサイドバーに配置することもできます)。
スタンドアロンのブロックコンポーネントは、クライアントのカスタマイズを柔軟かつ保守可能なアプローチで構築するための最も役立つツールです。これをサポートするための一般的な道筋があれば素晴らしいでしょう。
「いいね！」 3
これを再度取り上げたいと思います。コンポーネントの最適な処理方法を考えているのですが、現在、どちらも大きな欠点がある2つの選択肢があります。ブロックをレンダリングするテーマコンポーネントごとにレジストリを作成できますが、それはモジュラーの目的を損なうようなものです。または、プラグインを通じてグローバルに追加しますが、そうするとコンポーネントはそのプラグインがインストールされているかどうかに依存することになります。
そのため、コアにグローバルなブロック登録APIがあれば、非常に役立つと思われます。テーマコンポーネントがブロックレンダリングを呼び出すため、また新しいブロックを登録するために使用できるものです。
ブロックアプローチで作業するのが好きなのは、アプリのレイアウトとコンポーネントのコンテンツの間で関心を分割できるからです。ブロックコンポーネントはコンテンツのレンダリングのみを処理し、その後アプリの別のコンポーネントによってレンダリングされます。ブロックコンポーネントからルートとアウトレットのロジックをすべて削除でき、同じブロックをレイアウト上、さらにはアプリ全体で複数回簡単に再利用できます。
すべてがよりスリムで再利用可能になり、全体的にエレガントなアプローチになると考えています。Discourseでこのパターンをしっかりとサポートできれば素晴らしいでしょう。
「いいね！」 4