David, ci sono piani per cessare il supporto per i componenti “split” e i “.gjs” “non”?
Probabilmente sì. Sembra che js/hbs separati saranno supportati da ember per il prevedibile futuro, ma potrebbe avere senso per noi muoverci prima per semplificare i nostri sistemi di build di temi/plugin.
Se decidessimo di deprecare hbs, seguiremo tutto il normale ciclo di deprecazione e gli annunci, quindi non sarà una sorpresa.
Per temi/plugin che utilizzano la nostra configurazione di linting standard, i file .hbs sono già vietati e abbiamo uno strumento automatizzato per passare a gjs. Abbiamo quasi finito di aggiornare tutti i temi/plugin di proprietà di CDCK con questi strumenti.
5 Mi Piace
Quindi, solo per conferma (in modo che possa modificare i miei componenti js/hbs), i componenti hbs non sono supportati nello scheletro del tema ed è fortemente raccomandato di spostarli in gjs?
I file HBS continuano a essere “supportati” (ovvero, funzioneranno e non lo cambieremo senza un ciclo di deprecazione).
Ma sì, è fortemente raccomandato di utilizzare .gjs per il nuovo codice e di iniziare a migrare i temi e i plugin esistenti. La configurazione di linting più aggiornata negli scheletri applicherà tale raccomandazione a meno che tu non decida deliberatamente di rinunciare alla regola.
3 Mi Piace
Ah, capito ora. Grazie per il chiarimento!
2 Mi Piace
Credo che in ogni caso i Glimmer Components possano essere da 3 a 5 volte più veloci, quindi sicuramente una buona pratica?
3 Mi Piace
I componenti Glimmer sono significativamente più veloci dei componenti classici, yup!
Ma il formato di file .gjs non significa necessariamente che si tratti di un componente Glimmer. Abbiamo ancora centinaia di componenti classici nel core, che ora sono tutti convertiti nel formato di file .gjs. (la nomenclatura è confusionaria, lo so 
)
Il codemod che stiamo eseguendo esegue solo la conversione del formato di file da js/hbs → .gjs. Non cambia il tipo di componente, il che sarebbe quasi impossibile da automatizzare perfettamente.
4 Mi Piace
Giusto, ma spesso vale la pena fare lo sforzo se ti trovi nel bel mezzo di un refactoring manuale.
3 Mi Piace
OMG. Proprio quando pensavo di iniziare a capire.
Quindi non sono l’unico! 
Questo lo rende un componente glimmer?
E se fosse così; anche se è solo un template, aggiungere la classe lo rende più veloce rispetto a un .gjs che ha solo <template>Le mie parole importanti</template>?
export default class MyCoolComponent extends Component {
1 Mi Piace
È questo:
import Component from "@glimmer/component";
(e la successiva conformità alle norme di Glimmer.
2 Mi Piace
Ah! Quindi dovresti comunque dichiarare la classe per utilizzare la parte del componente importata.
Grazie mille!
3 Mi Piace
Il mio problema principale qui è che in un hbs posso semplicemente fare riferimento a un componente da un altro componente del tema poiché non ho bisogno di quell’importazione esplicita. Ma in un gjs devo importarlo e non ho idea di come fare riferimento a un componente definito in un altro componente del tema.
Tutte le implementazioni esistenti che ho esaminato o a) utilizzano ancora hbs o b) utilizzano l’iniezione basata su Javascript.
1 Mi Piace
In quel caso ottengo questa raccomandazione eslint:
Il che suggerisce che dovresti aggiungere la classe solo quando ne hai bisogno, altrimenti sarebbe effettivamente più lento.
1 Mi Piace
In ordine crescente di prestazioni:
-
Componente classico:
import Component from "@ember/component"; export default class Blah extends Component { -
Componente Glimmer:
import Component from "@glimmer/component"; export default class Blah extends Component { -
Componente Glimmer solo template:
export default <template> ... </template>
esatto
I temi attualmente non possono importare da altri temi. Il fatto che fosse possibile avere dipendenze inter-tema tramite la magica risoluzione basata sul nome non era in realtà intenzionale
Potresti espandere sul tuo caso d’uso, magari in un altro argomento? Non è qualcosa che abbiamo incontrato (ancora) per nessuno dei nostri temi.
3 Mi Piace
Penso che tu l’abbia fatto… (blocchi della barra laterale destra).
La scorsa settimana il mio caso d’uso principale è stato forzare un ordine per più componenti del tema che utilizzavano lo stesso plugin outlet. Mentre i file CSS vengono caricati in ordine alfabetico, il JS dei componenti del tema viene caricato in ordine numerico, quindi ho finito per rimuovere i componenti del tema e riaggiungerli nell’ordine di cui avevo bisogno, cercando di evitare tutti i problemi CSS che ciò causava allo stesso tempo.
Poi ho capito che potevo semplicemente rimuovere il connettore in ciascuno di essi e creare un nuovo componente del tema che avesse questo in un unico connettore per quel plugin outlet:
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
il che funziona molto bene. E poi ho pensato 'oh, ho bisogno che questo sia un gjs per evitare di dover rifare questo tra qualche mese. E poi 
1 Mi Piace
Hai un cliente che voleva farlo mentre si trasferiva da te. Non ricordo i dettagli.
Ho appena fatto un fork per un cliente attuale che ha appena lanciato. Voleva aggiungere un paio di altri tipi di blocchi. Ho provato ad avere un tema “sorella” che facesse solo cose di CSS ma alla fine ho dovuto rinunciare e fare un fork. Non sono abbastanza sicuro se ci potesse essere un altro modo.
1 Mi Piace
Ma…
2 Mi Piace
Sono ottime notizie, peccato non averlo capito prima. Mi sembra di averlo visto e ricordo anche di aver discusso del problema e qualcuno mi ha suggerito di fare un fork, ma ora sono abbastanza sicuro di non averne bisogno.
Hmmm … Discourse Bars 🍻 🍸 (a sidebar framework) … usa lo stesso sistema e non ho avuto problemi.
L’intero scopo è che puoi usare Componenti da altri Componenti del tema o Plugin (e funziona)
right-sidebar-blocks e discourse-tc-bars utilizzano entrambi il resolver Ember per cercare i componenti per nome. Al momento funziona e non è deprecato.
In .hbs viene fatto come {{component \"some-name\"}} e in (g)js può essere fatto come resolveRegistration(\"component:some-name\").
Ma se parliamo a lungo termine, allora dovremmo puntare a evitare di cercare componenti nel resolver Ember. Una volta che alla fine abiliteremo il flag “static invokables” di Embroider, il resolver sarà vuoto.
Questa è la direzione che penso dobbiamo prendere per right-sidebar-blocks e altre simili condivisioni di componenti cross-theme/plugin:
5 Mi Piace