David, gibt es Pläne, die Unterstützung für “Split”-Komponenten und “Non” .gjs einzustellen?
Wahrscheinlich ja. Es sieht so aus, als ob separate js/hbs auf absehbare Zeit von Ember unterstützt werden, aber es könnte für uns sinnvoll sein, früher einen Schritt zu machen, um unsere Theme-/Plugin-Build-Systeme zu vereinfachen.
Wenn wir uns entscheiden, hbs abzuschaffen, werden wir den gesamten normalen Abschaffungszyklus und die Ankündigungen durchlaufen, sodass es keine Überraschung sein wird.
Für Themes/Plugins, die unsere Standard-Linting-Konfiguration verwenden, sind .hbs-Dateien bereits verboten, und wir haben ein automatisches Tool, um zu gjs zu wechseln. Wir haben fast alle CDCK-eigenen Themes/Plugins mit diesen Werkzeugen aktualisiert.
5 „Gefällt mir“
Nur um das zu bestätigen (damit ich meine js/hbs-Komponenten bearbeiten kann): hbs-Komponenten werden im Theme-Skelett nicht unterstützt und es wird dringend empfohlen, sie zu gjs zu verschieben?
Hbs-Dateien werden weiterhin „unterstützt“ (d. h. sie funktionieren und wir werden das nicht ohne eine Veraltungsphase ändern).
Aber ja, es wird dringend empfohlen, .gjs für neuen Code zu verwenden und mit der Migration bestehender Themes und Plugins zu beginnen. Die aktuellste Linting-Konfiguration in den Skeletons erzwingt diese Empfehlung, es sei denn, Sie deaktivieren die Regel absichtlich.
3 „Gefällt mir“
Ah, jetzt habe ich es verstanden. Danke für die Klarstellung!
2 „Gefällt mir“
Ich glaube, dass Glimmer Components in jedem Fall 3 bis 5 Mal schneller sein können, also definitiv eine gute Vorgehensweise?
3 „Gefällt mir“
Glimmer-Komponenten sind deutlich schneller als klassische Komponenten, ja!
Aber das .gjs-Dateiformat bedeutet nicht zwangsläufig, dass es sich um eine Glimmer-Komponente handelt. Wir haben immer noch Hunderte von klassischen Komponenten im Kern, die jetzt alle in das .gjs-Dateiformat konvertiert wurden. (Die Benennung ist verwirrend, ich weiß 
)
Der von uns ausgeführte Codemod führt nur die Dateiformatkonvertierung von js/hbs → .gjs durch. Er ändert nicht den Komponententyp – das wäre fast unmöglich perfekt zu automatisieren.
4 „Gefällt mir“
Fair genug, aber es ist oft die Mühe wert, wenn man gerade mitten in einem manuellen Refactoring steckt.
3 „Gefällt mir“
OMG. Gerade als ich dachte, ich würde es langsam verstehen.
Also bin ich nicht der Einzige! 
Macht das daraus eine Glimmer-Komponente?
Und wenn das der Fall ist; selbst wenn es nur eine Vorlage ist, macht das Hinzufügen der Klasse sie schneller als eine .gjs-Datei, die nur \u003ctemplate\u003eMeine wichtigen Worte\u003c/template\u003e enthält?
export default class MyCoolComponent extends Component {
1 „Gefällt mir“
Es ist dies:
import Component from "@glimmer/component";
(und die anschließende Konformität mit den Glimmer-Normen.
2 „Gefällt mir“
Aha! Sie müssten also immer noch die Klasse deklarieren, um den importierten Komponenten-Teil zu verwenden.
Vielen Dank!
3 „Gefällt mir“
Mein Hauptproblem hier ist, dass ich in einer hbs einfach auf eine Komponente aus einer anderen Theme-Komponente verweisen kann, da ich diesen expliziten Import nicht benötige. Aber in einer gjs muss ich sie importieren und ich habe keine Ahnung, wie ich auf eine Komponente verweisen soll, die in einer anderen Theme-Komponente definiert ist.
Alle vorhandenen Implementierungen, die ich mir angesehen habe, verwenden entweder a) immer noch hbs oder b) Javascript-basierte Injection.
1 „Gefällt mir“
In diesem Fall erhalte ich diese ESLint-Empfehlung:
Dies legt nahe, dass Sie die Klasse nur hinzufügen sollten, wenn Sie sie benötigen, da sie andernfalls tatsächlich langsamer wäre.
1 „Gefällt mir“
In aufsteigender Reihenfolge der Leistung:
-
Klassische Komponente:
import Component from "@ember/component"; export default class Blah extends Component { -
Glimmer-Komponente:
import Component from "@glimmer/component"; export default class Blah extends Component { -
Nur-Template Glimmer-Komponente:
export default <template> ... </template>
genau
Themes können derzeit nicht aus anderen Themes importieren. Die Tatsache, dass es durch die magische namensbasierte Auflösung möglich war, Abhängigkeiten zwischen Themes zu haben, war nicht wirklich beabsichtigt
Könnten Sie Ihren Anwendungsfall vielleicht in einem anderen Thema näher erläutern? Wir sind (noch) nicht auf etwas derartiges für eines unserer eigenen Themes gestoßen.
3 „Gefällt mir“
Ich glaube, Sie haben… (Blöcke der rechten Seitenleiste).
Letzte Woche war mein Hauptanwendungsfall, eine Reihenfolge für mehrere Themenkomponenten zu erzwingen, die denselben Plugin-Outlet verwendeten. Während CSS-Dateien alphabetisch geladen werden, wird der JavaScript-Code der Themenkomponenten numerisch geladen. Daher habe ich am Ende Themenkomponenten entfernt und sie in der benötigten Reihenfolge wieder hinzugefügt und gleichzeitig versucht, alle CSS-Probleme zu vermeiden, die dies verursachte.
Dann kam ich auf die Idee, einfach den Connector in jedem von ihnen zu entfernen und eine neue Themenkomponente zu erstellen, die dies in einem einzigen Connector für diesen Plugin-Outlet hatte:
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
was sehr gut funktioniert. Und dann dachte ich: „Oh, ich brauche das als gjs, um dies in ein paar Monaten nicht wiederholen zu müssen. Und dann 
1 „Gefällt mir“
Sie haben einen Kunden, der dies tun wollte, als er zu Ihnen wechselte. Ich kann mich nicht an die Details erinnern.
Ich habe dies gerade für einen aktuellen Kunden geforkt, der gerade gestartet ist. Sie wollten ein paar andere Arten von Blöcken hinzufügen. Ich habe versucht, ein Schwesterthema zu haben, das nur CSS-Sachen gemacht hat, aber am Ende musste ich aufgeben und es forken. Ich bin mir nicht ganz sicher, ob es einen anderen Weg gegeben hätte.
1 „Gefällt mir“
Aber…
2 „Gefällt mir“
Das sind großartige Neuigkeiten, außer dass ich es nicht früher verstanden habe. Ich erinnere mich vage, das gesehen zu haben, und erinnere mich auch daran, das Problem besprochen zu haben, und jemand schlug vor, ich müsse forken (fork), aber jetzt bin ich mir ziemlich sicher, dass ich das nicht muss.
Hmmm … Discourse Bars 🍻 🍸 (a sidebar framework) … verwendet dasselbe System und ich hatte keine Probleme.
Der Sinn der Sache ist, dass Sie Komponenten aus anderen Theme Components oder Plugins verwenden können (und es funktioniert).
right-sidebar-blocks und discourse-tc-bars verwenden beide den Ember-Resolver, um Komponenten anhand ihres Namens nachzuschlagen. Derzeit funktioniert dies und ist nicht veraltet.
In .hbs geschieht dies wie {{component \"some-name\"}} und in (g)js kann dies wie resolveRegistration(\"component:some-name\") geschehen.
Wenn wir hier jedoch langfristig denken, sollten wir vermeiden, Komponenten über den Ember-Resolver nachzuschlagen. Sobald wir das Flag „static invokables“ von Embroider schließlich aktivieren, wird der Resolver leer sein.
Dies ist die Richtung, die wir meiner Meinung nach für right-sidebar-blocks und andere ähnliche Cross-Theme/Plugin-Komponentenfreigaben einschlagen müssen:
5 „Gefällt mir“