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

开发
1

David，是否有计划停止支持“split”组件和“non” .gjs？

1 个赞
2

可能是的。看起来在可预见的未来，ember 会支持单独的 js/hbs，但我们可能需要更早地做出改变，以简化我们的主题/插件构建系统。

如果我们决定弃用 hbs，我们会经历所有正常的弃用周期和公告，所以这不会是意外。

对于使用我们标准 linting 配置的主题/插件，.hbs 文件已经被禁止了，并且我们有一个自动化工具来迁移到 gjs。我们已经使用该工具几乎完成了所有 CDCK 拥有的主题/插件的更新。

5 个赞
3

所以，为了确认一下（这样我就可以编辑我的 js/hbs 组件），hbs 组件在主题骨架中不受支持，并且强烈建议迁移到 gjs 吗？

4

Hbs 文件将继续被“支持”（即它们可以工作，并且我们不会在没有弃用周期的情况下更改它）

但是，是的，强烈建议新代码使用 .gjs，并开始迁移现有主题和插件。骨架中最新的 linting 配置将强制执行该建议，除非您故意选择退出该规则。

3 个赞
5

啊，明白了。谢谢你的澄清！

2 个赞
6

我认为无论如何，Glimmer 组件的速度可以快 3 到 5 倍，所以绝对是好的实践吗？

3 个赞
7

Glimmer 组件比经典组件快得多，是的！

但 .gjs 文件格式并不一定意味着它是 glimmer 组件。我们核心中仍有数百个经典组件，现在都已转换为 .gjs 文件格式。（我知道命名很令人困惑 :sweat_smile:）

我们运行的代码转换器仅执行文件格式从 js/hbs → .gjs 的转换。它不会更改组件类型——这几乎不可能完美地自动化。

4 个赞
8

说得有理，但如果你正好在手动重构的过程中，通常值得为此付出努力。

3 个赞
9

我的天。我刚以为我开始明白了。

所以不是我一个人这么觉得！ :tada:

这会让它成为一个 Glimmer 组件吗？

而且，如果是这样的话；即使它只是一个模板，添加类也会比一个只有 <template>我的重要词语</template> 的 .gjs 文件运行得更快吗？

export default class MyCoolComponent extends Component {
1 个赞
10

它是这样的：

import Component from "@glimmer/component";

（以及后续对 Glimmer 规范的遵守。）

2 个赞
11

啊哈！所以你仍然需要声明类才能使用导入的组件部分。

非常感谢！

3 个赞
12

我目前的主要问题是，在 hbs 文件中，我可以简单地引用另一个主题组件中的组件，因为我不需要显式导入。但是在 gjs 文件中，我需要 import 它，而且我不知道如何引用在另一个主题组件中定义的组件。

我所查看的所有现有实现要么是 a) 仍然使用 hbs，要么是 b) 使用基于 Javascript 的注入。

1 个赞
13

在这种情况下，我会收到此 eslint 建议：

这表明您应该仅在需要时才添加类，否则它实际上会变慢。

1 个赞
14

按性能升序排列：

  • Classic 组件：

    import Component from "@ember/component";
export default class Blah extends Component {

  • Glimmer 组件：

    import Component from "@glimmer/component";
export default class Blah extends Component {

  • 仅模板的 Glimmer 组件：

    export default <template> ... </template>

:100: 完全正确

主题目前无法从其他主题导入。通过基于名称的魔法解析实现主题间依赖关系的可能性实际上并非有意为之 :sweat_smile:

您能否在另一个主题中扩展您的用例？我们（到目前为止）还没有在任何我们自己的主题中遇到过这种情况。

3 个赞
15

我认为您已经…（右侧边栏块）。

上周我的主要用例是强制对使用相同插件插口的多个主题组件进行排序。虽然 CSS 文件按字母顺序加载，但主题组件的 JS 是按数字顺序加载的，所以我最终删除了主题组件，并按照我需要的顺序重新添加它们，同时试图避免所有这些 CSS 问题。

然后我想，我可以删除每个组件中的连接器，并创建一个新的主题组件，该组件在单个连接器中包含此插件插口：

<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />

这效果非常好。然后我想：“哦，我需要将其设为 gjs，以免几个月后不得不重新做一遍。” 然后 :exploding_head:

1 个赞
16

您有一位客户在迁移到您这里时希望这样做。我不记得具体细节了。

我刚刚为一位刚上线的客户分叉了这个。他们想添加其他几种类型的块。我尝试过一个只做一些 CSS 的姐妹主题，但最终不得不放弃并分叉它。我不确定是否还有其他方法。

1 个赞
17

但是……

2 个赞
18

这是个好消息，只是我没有早点明白。我有点记得看到过这个，也记得讨论过这个问题，有人建议我需要 fork (派生)，但现在我很确定我不需要了。

19

嗯…… https://meta.discourse.org/t/discourse-bars-a-sidebar-framework/298216…… 使用的是相同的系统，我没有遇到问题。

它的重点在于你可以使用来自其他主题组件或插件的组件（并且它确实有效）。

20

right-sidebar-blocks 和 discourse-tc-bars 都使用 Ember 解析器按名称查找组件。目前这可以正常工作，并且没有被弃用。

在 .hbs 中，它通过 {{component \"some-name\"}} 完成，在 (g)js 中，可以通过 resolveRegistration(\"component:some-name\") 完成。

但如果从长远来看，那么我们应该避免在 Ember 解析器上查找组件。一旦我们最终启用 Embroider 的“静态可调用”标志，解析器将为空。

我认为这就是我们需要为 right-sidebar-blocks 和其他类似的跨主题/插件组件共享采取的方向：

5 个赞