David, are there plans to cease support for “split” components and “non .gjs” at some stage?

[תמונה] david: But the .gjs file format does not necessarily mean it’s a glimmer component. OMG. Just when I thought I was starting to understand. [תמונה] david: (naming is confusing, I know :sweat_smile:) So it’s not just me! :tada: Does this make it be a glimmer component? And if that’s the case; even if it’s just a template, adding the class makes it run faster than if it’s a .gjs that has just My important words ? export default class MyCoolComponent extends Component {

It’s this: import Component from "@glimmer/component"; (and subsequent conformance to Glimmer norms like getters) [תמונה] pfaffman: export default class MyCoolComponent extends Component { this is just a “Native class declaration” I believe.

[תמונה] merefield: It’s this: import Component from "@glimmer/component"; Aha! So you’d still need to declare the class to use the imported component part. Thanks very much!

My main issue here is that in a hbs I can simply reference a component from another theme component since I don’t need that explicit import. But in a gjs I need to import it and I have no idea how to reference a component defined in another theme component. All the existing implementations I have looked at are either a) still using hbs or b) using Javascript based injection. How do I do this?

[תמונה] pfaffman: And if that’s the case; even if it’s just a template, adding the class makes it run faster than if it’s a .gjs that has just My important words ? In that case I get this eslint recommendation: docs/rules/no-empty-glimmer-component-classes.md master # ember/no-empty-glimmer-component-classes 💼 This rule is enabled in the ✅ `recommended` [config](https://github.com/ember-cli/eslint-plugin-ember#-configurations). This rule will catch and prevent the use of empty backing classes for Glimmer components. ## Rule Details This rule aims to disallow the use of empty backing classes for Glimmer components when possible including only using ember template tags in your Glimmer component. Template-only Glimmer components where there is no backing class are much faster and lighter-weight than Glimmer components with backing classes, which are much lighter-weight than Ember components. Therefore, you should only have a backing class for a Glimmer component when absolutely necessary. An exception to this case is if you need the component to be generic over part of its type signature. To fix violations of this rule: - In apps: Remove the backing class entirely until it is actually needed. - In in-repo addons: Replace the backing class depending on what the host app is doing. That is, if `template-only-glimmer-components` is enabled, remove the backing class. Otherwise, replace it with a `templateOnly` export. - In other addons: Replace the backing class with a `templateOnly` export. This is necessary because you can't assume `template-only-glimmer-components` is enabled. ## Examples This file has been truncated. show original Which suggests you should only add the class when you need it as otherwise it would actually be slower.

[תמונה] pfaffman: Does this make it be a glimmer component? In ascending order of performance: Classic component: import Component from "@ember/component"; export default class Blah extends Component { Glimmer component: import Component from "@glimmer/component"; export default class Blah extends Component { Template-only glimmer component: export default ... [תמונה] manuel: Which suggests you should only add the class when you need it as otherwise it would actually be slower. :100: exactly [תמונה] RGJ: I have no idea how to reference a component defined in another theme component. Themes cannot currently import from other themes. The fact it was possible to have inter-theme dependencies via the magic name-based-resolution wasn’t really intentional :sweat_smile: Could you expand on your use-case, perhaps in another topic? It isn’t something we’ve come across (yet) for any of our own themes.

[תמונה] david: Could you expand on your use-case, perhaps in another topic? It isn’t something we’ve come across (yet) for any of our own themes. I think you have… (right-sidebar-blocks). Last week my main use case was to force an order for multiple theme components that used the same plugin outlet. While CSS files are loaded in alphabetic order, the theme components JS is loaded in numerical order, so I ended up removing theme components and adding them back in the order I needed and trying to avoid all the CSS problems that this caused at the same time. Then I figured I could just remove the connector in each of them and create a new theme component that had this in a single connector for that plugin outlet: which works really well. And then I was like 'oh, I need this to be a gjs to avoid having to redo this in a few months. And then :exploding_head:

[תמונה] david: Could you expand on your use-case, perhaps in another topic? It isn’t something we’ve come across (yet) for any of our own themes. You have a customer that wanted to do this as they were moving to you. I can’t remember the details. [תמונה] RGJ: I think you have… (right-sidebar-blocks). I just forked this for a current customer that just launched. They wanted to add a couple of other kinds of blocks. I tried having a sister theme that did just some CSS stuff but in the end had to give up and fork it. I’m not quite sure if there could have been another way.

[תמונה] pfaffman: They wanted to add a couple of other kinds of blocks But… [תמונה]Right Sidebar Blocks You can also use other Ember components as blocks, you just need to use the correct name. For example, core includes a signup-cta Ember component, and you can use it in the sidebar as is. Note that you can’t use components that expect a set of parameters, but you can build your own Ember component in a separate theme and reference it just by its name in the sidebar’s blocks setting.

That is great news, except that I didn’t understand sooner. I sort of remember seeing that and also remember discussing the issue and someone suggested I need to fork, but now I’m pretty sure that I don’t.

מתי להחליף ערכות נושא/תוספים ל-`.gjs`?

מפתח

RGJ (Richard - Communiteq) 13 ביוני,‏ 2025,‏ 7:55pm 17

But…

נושא		תגובות	צפיות
Modernizing inline script tags for templates & JS API Development dev-news	46	6306	25 במרץ,‏ 2026
Templating of my "component" broke. How do I fix it? Development	14	583	17 במרץ,‏ 2026
Upgrading Discourse to Ember 4 Development ember	19	3543	19 בדצמבר,‏ 2024
Overriding plugin javascript in a theme component Development	11	1442	10 באוקטובר,‏ 2022
Javascript assets in a theme component Development	15	2586	7 במאי,‏ 2021

מתי להחליף ערכות נושא/תוספים ל-`.gjs`?

נושאים קשורים