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

מפתח
1

דייויד, האם יש תוכניות להפסיק את התמיכה ברכיבי “split” וב- “.gjs שאינם”?

לייק 1
2

Probably yes. It looks like separate js/hbs will be supported by ember for the foreseeable future, but it may make sense for us to make a move earlier to simplify our theme/plugin build systems.

If we do decide to deprecate hbs, we’ll go through all the normal deprecation cycle and announcements, so it won’t come as a surprise.

For themes/plugins using our standard linting config, .hbs files are already banned, and we have an automated tool to move to gjs. We’ve almost finished updating all CDCK-owned themes/plugins with that tooling.

5 לייקים
3

רק כדי לוודא (כדי שאוכל לערוך את רכיבי ה-js/hbs שלי), רכיבי hbs אינם נתמכים בתבנית הבסיס של העיצוב, ומומלץ מאוד להעביר אותם ל-gjs?

4

קבצי Hbs ימשיכו להיות “נתמכים” (כלומר, הם יעבדו, ולא נשנה זאת ללא מחזור הוצאה משימוש)

אבל כן, מומלץ מאוד להשתמש ב-.gjs לקוד חדש, ולהתחיל להעביר ערכות נושא ותוספים קיימים. תצורת ה-linting העדכנית ביותר בסקלטונים תאכוף את ההמלצה הזו אלא אם תבחר לבטל את הכלל בכוונה.

3 לייקים
5

אה, הבנתי עכשיו. תודה על ההבהרה!

2 לייקים
6

אני מאמין שבכל מקרה רכיבי Glimmer יכולים להיות מהירים פי 3 עד 5, אז בהחלט תרגול טוב?

3 לייקים
7

Glimmer components are significantly faster than classic components, yup!

But the .gjs file format does not necessarily mean it’s a glimmer component. We still have hundreds of classic components in core, which are now all converted to the .gjs file format. (naming is confusing, I know :sweat_smile:)

The codemod we’re running only does the file format conversion from js/hbs → .gjs. It doesn’t change the component type - that would be almost impossible to perfectly automate.

4 לייקים
8

Fair enough, but often worth making the effort if you happen to be in the middle of a manual refactor.

3 לייקים
9

OMG. Just when I thought I was starting to understand.

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 <template>My important words</template>?

export default class MyCoolComponent extends Component {
לייק 1
10

זה זה:

import Component from "@glimmer/component";

(ותאימות לאחר מכן לנורמות של Glimmer.

2 לייקים
11

Aha! So you’d still need to declare the class to use the imported component part.

Thanks very much!

3 לייקים
12

הבעיה העיקרית שלי כאן היא שב-hbs אני יכול פשוט להתייחס לרכיב מרכיב ערכת נושא אחר מכיוון שאני לא צריך את הייבוא המפורש הזה. אבל ב-gjs אני צריך import אותו ואין לי מושג איך להתייחס לרכיב המוגדר ברכיב ערכת נושא אחר.

כל היישומים הקיימים שבדקתי הם או א) עדיין משתמשים ב-hbs או ב) משתמשים בהזרקה מבוססת Javascript.

לייק 1
13

In that case I get this eslint recommendation:

Which suggests you should only add the class when you need it as otherwise it would actually be slower.

לייק 1
14

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 <template> ... </template>

:100: exactly

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.

3 לייקים
15

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:

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

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:

לייק 1
16

You have a customer that wanted to do this as they were moving to you. I can’t remember the details.

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.

לייק 1
17

But…

2 לייקים
18

אלה חדשות נהדרות, מלבד העובדה שלא הבנתי קודם. אני די זוכר שראיתי את זה וגם זוכר שדנו בנושא ומישהו הציע שאני צריך לעשות פורק (fork), אבל עכשיו אני די בטוח שאני לא צריך.

19

Hmmm … Discourse Bars 🍻 🍸 (a sidebar framework) … uses the same system and I’ve not had issues.

The whole point of it is you can use Components from other Theme Components or Plugins (and it works)

20

right-sidebar-blocks and discourse-tc-bars are both using the Ember resolver to lookup components by name. Right now that works, and is not deprecated.

In .hbs it’s done like {{component "some-name"}}, and in (g)js it can be done like resolveRegistration("component:some-name").

But if we’re talking long-term here, then we should be aiming to avoid looking up components on the Ember resolver. Once we eventually enable Embroider’s “static invokables” flag, the resolver will be empty.

This is the direction I think we need to take for right-sidebar-blocks, and other similar cross-theme/plugin component sharing:

5 לייקים