# 何时将主题/插件切换到 \`.gjs\`？

**URL:** https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063
**Category:** Development
**Created:** [2025年六月13日 10:15 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063 "2025-06-13T10:15:31Z")
**Posts on this page:** 8
**Page:** 2

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2025年六月22日 16:22 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/21 "2025-06-22T16:22:40Z")

</div>

> [@david](#):
>
> 但如果我们着眼于长期发展，那么我们应该致力于避免在 Ember 解析器中查找组件。一旦我们最终启用 Embroider 的“静态可调用”标志，解析器将为空。

我认为我们需要一种通用的方法来做到这一点，这种方法不依赖于特定的主题组件——就像我们现在一样。

我还有另一个使用这种技术的主题组件：

> **[The Home Pages Add-on - integrate static content from Landing Pages and add...](https://coop.pavilion.tech/t/the-home-pages-add-on-integrate-static-content-from-landing-pages-and-add-dynamic-pages-too/3554)**
>
> What are “Dynamic” and “Simple Pages” There are special pages facilitated by the Pavilion Landing Pages plugin and the new Home Pages Theme Component. The new Home Pages Theme Component is required to blend the content of the Landing Pages into...

所以至少有我这边的两个，可能还有更多。

---

<div class="post-metadata">

### Author: ![manuel](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/manuel/32/468169_2.png) [@manuel](https://meta.discourse.org/u/manuel)
#### Post date: [2025年六月22日 16:41 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/22 "2025-06-22T16:41:43Z")

</div>

> [@merefield](#):
>
> 我认为我们需要一种通用的方法来做到这一点

我同意。我构建了一个块组件集合，每个组件都是独立的，而不是捆绑在一个包中：[https://gitlab.com/manuelkostka/discourse/blocks。](https://gitlab.com/manuelkostka/discourse/blocks%E3%80%82)

现在，我可以使用我的 Homepage Blocks 组件将这些块放在一个专用的主页上，就像我可以使用 Right Sidebar Blocks 或 Bars 一样。

我最近在 Central 主题上做了一个尝试，我需要一个自定义侧边栏布局。我可以轻松地为自定义侧边栏构建一个块框架，并将块组件放在上面：[https://central.kostka.studio](https://central.kostka.studio)（只需通过名称引用，就可以将 _Powered-by-discourse_ 组件放在侧边栏上）。

独立的块组件确实是我目前用于以灵活且可维护的方式构建客户端自定义的最有用的工具。很高兴能有一个通用的前进方向来支持这一点。

---

<div class="post-metadata">

### Author: ![manuel](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/manuel/32/468169_2.png) [@manuel](https://meta.discourse.org/u/manuel)
#### Post date: [2025年八月15日 17:07 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/23 "2025-08-15T17:07:08Z")

</div>

> [@merefield](#):
>
> 我认为我们需要一种通用的方法来做到这一点，这种方法不依赖于特定的主题组件——就像我们现在一样。

我想顶一下这个帖子，因为我正在尝试找出处理组件的最佳方法。目前我看到两个选项，它们都有很大的缺点：我可以为每个渲染块的主题组件创建一个注册表，但这在某种程度上违背了模块化的初衷。或者通过插件全局添加一个注册表，但这样我的组件就会依赖于该插件的安装。

因此，在核心中拥有一个全局块注册 API 似乎会非常有帮助。主题组件可以使用它来调用块渲染，也可以注册新块。

我喜欢使用块方法，因为它允许我在应用程序布局和组件内容之间分离关注点。块组件只负责渲染其内容，然后由应用程序中的另一个组件进行渲染。我可以从块组件中删除所有路由和出口逻辑，并且可以轻松地在布局中甚至在整个应用程序中多次重用同一个块。

我认为这使得一切都更精简、更具可重用性，并且总体上是一种优雅的方法。在 Discourse 中获得对这种模式的有力支持将是很好的。

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2025年十二月31日 16:24 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/24 "2025-12-31T16:24:08Z")

</div>

David，是否可以有一个任意的 API 来注册“跨主题/插件”组件供另一个插件/组件使用？

这样可以避免注册所有内容，同时仍然提供明确实现此目的的灵活性。

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [2026年一月5日 10:47 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/25 "2026-01-05T10:47:29Z")

</div>

我不确定是否应该为此提供一个通用的应用程序编程接口（API）。组件的使用方式太多了，它们对参数和加载时机都有不同的期望。

对于您的用例，一个特定于主题/插件的注册表是否可行？就像上面关于 [right-sidebar-blocks](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/20?u=david) 的模型一样？

如果不可行，提供一些具体的例子可能有助于我们弄清楚到底需要什么样的 API。所有由 CDCK 维护的主题和插件都已迁移到 gjs，除了像 right-sidebar-blocks 这样的特定情况外，我们没有遇到这个问题。

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2026年一月5日 11:00 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/26 "2026-01-05T11:00:05Z")

</div>

> [@david](#):
>
> 对于您的用例，主题/插件特定的注册表是否可行？就像上面 [针对 right-sidebar-blocks](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/20) 的模型一样？

是的，实际上，仔细重读您在草稿 PR 上所写的内容，确实让我相信这是一个足够好的解决方案，特别是：

“此提交引入了一个专用的右侧边栏块组件列表，并允许其他主题/插件注册其他组件。”

我认为这是关键——能够远程注册为与另一个主题兼容，然后允许“主”主题合并远程注册的元素，这正是我想要的，所以我认为您已经证明了这是可行的。

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [2026年一月5日 11:01 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/27 "2026-01-05T11:01:18Z")

</div>

太棒了！

> [@merefield](#):
>
> 允许“主”主题整合远程注册的元素

在非常简单的情况下，您甚至可以尝试在“主”主题中添加一个 `PluginOutlet`，然后其他主题可以 `renderInOutlet`（或将文件放入 `connectors/...`）。

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2026年一月5日 11:03 UTC](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063/28 "2026-01-05T11:03:07Z")

</div>

同样属实。但我真的很喜欢你的注册模式，非常棒。实际上，保留与 RSB 的兼容性会很好（Bars 已经使用相同的参数系统），这样整个系统就可以互操作（尽管有两个初始化器可能会是个挑战——或者如果我能关闭 RSB 布局层，可能就不需要额外的初始化器了，这样就可以简单地完全加载 RSB 并重复使用 🤔）。

[上一頁](https://meta.discourse.org/t/when-to-switch-themes-plugins-to-gjs/370063.md?page=1)
