David, existem planos para cessar o suporte para componentes “split” e “.gjs não”?
Provavelmente sim. Parece que js/hbs separados serão suportados pelo ember no futuro previsível, mas pode fazer sentido para nós darmos um passo mais cedo para simplificar nossos sistemas de build de temas/plugins.
Se decidirmos descontinuar o hbs, passaremos por todo o ciclo normal de descontinuação e anúncios, então não será uma surpresa.
Para temas/plugins que usam nossa configuração de linting padrão, os arquivos .hbs já estão banidos, e temos uma ferramenta automatizada para migrar para gjs. Quase terminamos de atualizar todos os temas/plugins de propriedade da CDCK com essa ferramenta.
5 curtidas
Então, só para confirmar (para que eu possa editar meus componentes js/hbs), os componentes hbs não são suportados no esqueleto do tema, e é fortemente recomendado que sejam movidos para gjs?
Arquivos Hbs continuam a ser “suportados” (ou seja, eles funcionarão, e não mudaremos isso sem um ciclo de depreciação)
Mas sim, é altamente recomendável usar .gjs para código novo e começar a migrar temas e plugins existentes. A configuração de linting mais atualizada nos esqueletos aplicará essa recomendação, a menos que você opte deliberadamente por não usar a regra.
3 curtidas
Ah, entendi agora. Obrigado por esclarecer!
2 curtidas
Acredito que, em qualquer caso, os Componentes Glimmer podem ser de 3 a 5 vezes mais rápidos, então definitivamente é uma boa prática?
3 curtidas
Os componentes Glimmer são significativamente mais rápidos que os componentes clássicos, sim!
Mas o formato de arquivo .gjs não significa necessariamente que é um componente Glimmer. Ainda temos centenas de componentes clássicos no core, que agora foram todos convertidos para o formato de arquivo .gjs. (a nomenclatura é confusa, eu sei 
)
O codemod que estamos executando apenas faz a conversão do formato de arquivo de js/hbs → .gjs. Ele não muda o tipo do componente - isso seria quase impossível de automatizar perfeitamente.
4 curtidas
Justo, mas muitas vezes vale a pena fazer o esforço se você estiver no meio de uma refatoração manual.
3 curtidas
OMG. Assim que pensei que estava começando a entender.
Então não sou só eu! 
Isso o torna um componente Glimmer?
E se for esse o caso; mesmo que seja apenas um template, adicionar a classe o faz rodar mais rápido do que se fosse um .gjs que tem apenas <template>Minhas palavras importantes</template>?
export default class MyCoolComponent extends Component {
1 curtida
É isto:
import Component from "@glimmer/component";
(e subsequente conformidade com as normas Glimmer.
2 curtidas
Aha! Então você ainda precisaria declarar a classe para usar a parte do componente importada.
Muito obrigado!
3 curtidas
Meu principal problema aqui é que em um hbs eu posso simplesmente referenciar um componente de outro componente de tema, já que não preciso daquela importação explícita. Mas em um gjs eu preciso importar e não tenho ideia de como referenciar um componente definido em outro componente de tema.
Todas as implementações existentes que eu vi são a) ainda usando hbs ou b) usando injeção baseada em Javascript.
1 curtida
Nesse caso, recebo esta recomendação do eslint:
Que sugere que você só deve adicionar a classe quando precisar dela, pois, caso contrário, ela seria mais lenta.
1 curtida
Em ordem crescente de desempenho:
-
Componente clássico:
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 somente de template:
export default <template> ... </template>
exatamente
Os temas atualmente não podem importar de outros temas. O fato de ter sido possível ter dependências inter-temas através da mágica resolução baseada em nome não foi realmente intencional
Você poderia expandir seu caso de uso, talvez em outro tópico? Não é algo que encontramos (ainda) para nenhum de nossos próprios temas.
3 curtidas
Acho que você tem… (blocos da barra lateral direita).
Na semana passada, meu principal caso de uso foi forçar uma ordem para vários componentes de tema que usavam o mesmo plugin outlet. Enquanto os arquivos CSS são carregados em ordem alfabética, o JS dos componentes de tema é carregado em ordem numérica, então acabei removendo os componentes de tema e adicionando-os de volta na ordem que eu precisava, tentando evitar todos os problemas de CSS que isso causou ao mesmo tempo.
Então, pensei que poderia simplesmente remover o conector em cada um deles e criar um novo componente de tema que tivesse isso em um único conector para aquele plugin outlet:
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
o que funciona muito bem. E então eu pensei 'oh, eu preciso que isso seja um gjs para evitar ter que refazer isso em alguns meses. E então 
1 curtida
Você tem um cliente que queria fazer isso ao mudar para você. Não me lembro dos detalhes.
Acabei de fazer um fork disso para um cliente atual que acabou de lançar. Eles queriam adicionar alguns outros tipos de blocos. Tentei ter um tema irmão que fizesse apenas algumas coisas de CSS, mas no final tive que desistir e fazer um fork. Não tenho certeza se poderia ter havido outra maneira.
1 curtida
Mas…
2 curtidas
Essa é uma ótima notícia, exceto que eu não entendi antes. Eu meio que me lembro de ter visto isso e também me lembro de discutir o problema e alguém sugeriu que eu precisava fazer um fork, mas agora tenho quase certeza de que não preciso.
Hmmm … Discourse Bars 🍻 🍸 (a sidebar framework) … usa o mesmo sistema e eu não tive problemas.
O objetivo principal é que você pode usar Componentes de outros Componentes de Tema ou Plugins (e funciona)
right-sidebar-blocks e discourse-tc-bars estão ambos usando o Ember resolver para procurar componentes por nome. No momento, isso funciona e não é obsoleto.
Em .hbs é feito como {{component \"some-name\"}} e em (g)js pode ser feito como resolveRegistration(\"component:some-name\").
Mas se estivermos falando a longo prazo, então devemos ter como objetivo evitar a procura de componentes no Ember resolver. Assim que eventualmente habilitarmos a flag “static invokables” do Embroider, o resolver ficará vazio.
Esta é a direção que acho que precisamos tomar para right-sidebar-blocks e outros compartilhamentos de componentes semelhantes entre temas/plugins:
5 curtidas