David, est-il prévu d’arrêter la prise en charge des composants “split” et des “.gjs” “non” ?
Probablement oui. Il semble que les fichiers .js/.hbs séparés seront pris en charge par Ember dans un avenir prévisible, mais il pourrait être judicieux pour nous d’agir plus tôt pour simplifier nos systèmes de build de thèmes/plugins.
Si nous décidons de déprécier les .hbs, nous passerons par le cycle de dépréciation et les annonces habituels, donc cela ne sera pas une surprise.
Pour les thèmes/plugins utilisant notre configuration de linting standard, les fichiers .hbs sont déjà interdits, et nous avons un outil automatisé pour passer au format .gjs. Nous avons presque terminé la mise à jour de tous les thèmes/plugins appartenant à CDCK avec ces outils.
5 « J'aime »
Donc, juste pour confirmer (afin que je puisse modifier mes composants js/hbs), les composants hbs ne sont pas pris en charge dans le squelette du thème, et il est fortement recommandé de les déplacer vers gjs ?
Les fichiers Hbs continuent d’être “pris en charge” (c’est-à-dire qu’ils fonctionneront, et nous ne changerons pas cela sans un cycle de dépréciation)
Mais oui, il est fortement recommandé d’utiliser .gjs pour le nouveau code, et de commencer à migrer les thèmes et les plugins existants. La configuration de linting la plus récente dans les squelettes appliquera cette recommandation, sauf si vous choisissez délibérément de vous retirer de la règle.
3 « J'aime »
Ah, je comprends maintenant. Merci pour ces éclaircissements
bsp!
2 « J'aime »
Je crois que dans tous les cas, les composants Glimmer peuvent être de 3 à 5 fois plus rapides, donc certainement une bonne pratique ?
3 « J'aime »
Les composants Glimmer sont nettement plus rapides que les composants classiques, ouais !
Mais le format de fichier .gjs ne signifie pas nécessairement qu’il s’agit d’un composant Glimmer. Nous avons encore des centaines de composants classiques dans le cœur, qui sont maintenant tous convertis au format de fichier .gjs. (La nomenclature est confuse, je sais 
)
Le codemod que nous exécutons ne fait que la conversion du format de fichier de js/hbs vers .gjs. Il ne change pas le type de composant - ce serait presque impossible à automatiser parfaitement.
4 « J'aime »
C’est juste, mais cela vaut souvent la peine de faire l’effort si vous êtes en plein milieu d’une refonte manuelle.
3 « J'aime »
OMG. Juste au moment où je pensais commencer à comprendre.
Donc ce n’est pas juste moi ! 
Est-ce que cela en fait un composant Glimmer ?
Et si c’est le cas ; même si ce n’est qu’un modèle, l’ajout de la classe le fait-il fonctionner plus rapidement que s’il s’agit d’un .gjs qui contient juste My important words ?
export default class MyCoolComponent extends Component {
1 « J'aime »
C’est ceci :
import Component from "@glimmer/component";
(et la conformité subséquente aux normes Glimmer.
2 « J'aime »
Ah ! Il faudrait donc toujours déclarer la classe pour utiliser la partie du composant importée.
Merci beaucoup !
3 « J'aime »
Mon principal problème ici est que dans un hbs, je peux simplement référencer un composant d’un autre composant de thème car je n’ai pas besoin de cet import explicite. Mais dans un gjs, je dois l’importer et je n’ai aucune idée de comment référencer un composant défini dans un autre composant de thème.
Toutes les implémentations existantes que j’ai examinées sont soit a) toujours en utilisant hbs soit b) en utilisant l’injection basée sur Javascript.
1 « J'aime »
Dans ce cas, j’obtiens cette recommandation eslint :
Ce qui suggère que vous ne devriez ajouter la classe que lorsque vous en avez besoin, car sinon ce serait en fait plus lent.
1 « J'aime »
Par ordre croissant de performance :
-
Composant classique :
import Component from "@ember/component"; export default class Blah extends Component { -
Composant Glimmer :
import Component from "@glimmer/component"; export default class Blah extends Component { -
Composant Glimmer uniquement par template :
export default <template> ... </template>
exactement
Les thèmes ne peuvent actuellement pas importer depuis d’autres thèmes. Le fait qu’il ait été possible d’avoir des dépendances inter-thèmes via la résolution magique basée sur le nom n’était pas vraiment intentionnel
Pourriez-vous développer votre cas d’utilisation, peut-être dans un autre sujet ? Ce n’est pas quelque chose que nous avons rencontré (jusqu’à présent) pour aucun de nos propres thèmes.
3 « J'aime »
Je pense que vous l’avez… (blocs de la barre latérale droite).
La semaine dernière, mon principal cas d’utilisation était de forcer un ordre pour plusieurs composants thématiques qui utilisaient le même point de sortie de plugin. Alors que les fichiers CSS sont chargés par ordre alphabétique, le JS des composants thématiques est chargé par ordre numérique, j’ai donc fini par supprimer des composants thématiques et les ajouter à nouveau dans l’ordre dont j’avais besoin, tout en essayant d’éviter tous les problèmes CSS que cela causait.
Ensuite, j’ai pensé que je pourrais simplement supprimer le connecteur dans chacun d’eux et créer un nouveau composant thématique qui avait ceci dans un seul connecteur pour ce point de sortie de plugin :
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
ce qui fonctionne très bien. Et puis je me suis dit « oh, j’ai besoin que ce soit un gjs pour éviter d’avoir à refaire cela dans quelques mois. Et puis 
1 « J'aime »
Vous avez un client qui voulait faire cela en migrant vers vous. Je ne me souviens pas des détails.
Je viens de forker ceci pour un client actuel qui vient de lancer. Ils voulaient ajouter quelques autres types de blocs. J’ai essayé d’avoir un thème sœur qui faisait juste des trucs CSS, mais j’ai finalement dû abandonner et le forker. Je ne suis pas tout à fait sûr s’il aurait pu y avoir une autre façon.
1 « J'aime »
Mais…
2 « J'aime »
C’est une excellente nouvelle, sauf que je n’ai pas compris plus tôt. Je me souviens vaguement d’avoir vu ça et je me souviens aussi d’avoir discuté du problème et quelqu’un a suggéré que je devais faire un fork, mais maintenant je suis presque sûr que je n’en ai pas besoin.
Hmmm… Discourse Bars 🍻 🍸 (a sidebar framework)… utilise le même système et je n’ai pas eu de problèmes.
Le but est que vous puissiez utiliser des Composants d’autres Composants de Thème ou Plugins (et cela fonctionne)
right-sidebar-blocks et discourse-tc-bars utilisent tous deux le résolveur Ember pour rechercher des composants par leur nom. Pour l’instant, cela fonctionne et n’est pas déprécié.
En .hbs, cela se fait comme {{component \"some-name\"}}, et en (g)js, cela peut se faire comme resolveRegistration(\"component:some-name\").
Mais si nous parlons à long terme, alors nous devrions viser à éviter de rechercher des composants sur le résolveur Ember. Une fois que nous activerons éventuellement le drapeau « invocables statiques » d’Embroider, le résolveur sera vide.
C’est la direction que je pense que nous devons prendre pour right-sidebar-blocks, et d’autres partages de composants similaires entre thèmes/plugins :
5 « J'aime »