David, ¿hay planes para dejar de dar soporte a los componentes “split” y a los “.gjs” que no son “non”?
Probablemente sí. Parece que Ember admitirá archivos js/hbs separados en el futuro previsible, pero podría tener sentido que hagamos un movimiento antes para simplificar nuestros sistemas de compilación de temas/plugins.
Si decidimos dejar de admitir hbs, pasaremos por todo el ciclo de depreciación y los anuncios normales, por lo que no será una sorpresa.
Para temas/plugins que utilizan nuestra configuración de linting estándar, los archivos .hbs ya están prohibidos, y tenemos una herramienta automatizada para migrar a gjs. Casi hemos terminado de actualizar todos los temas/plugins propiedad de CDCK con esas herramientas.
5 Me gusta
Entonces, solo para confirmar (para poder editar mis componentes js/hbs), ¿los componentes hbs no son compatibles con el esqueleto del tema, y se recomienda encarecidamente que se muevan a gjs?
Los archivos Hbs siguen siendo “compatibles” (es decir, funcionarán y no cambiaremos eso sin un ciclo de obsolescencia).
Pero sí, se recomienda encarecidamente usar .gjs para el código nuevo y comenzar a migrar los temas y complementos existentes. La configuración de linting más actualizada en los esqueletos aplicará esa recomendación a menos que opte deliberadamente por no participar en la regla.
3 Me gusta
Ah, ahora lo entiendo. ¡Gracias por aclararlo!
2 Me gusta
Creo que, en cualquier caso, los componentes Glimmer pueden ser entre 3 y 5 veces más rápidos, así que, ¿definitivamente es una buena práctica?
3 Me gusta
Los componentes Glimmer son significativamente más rápidos que los componentes clásicos, ¡sí!
Pero el formato de archivo .gjs no significa necesariamente que sea un componente Glimmer. Todavía tenemos cientos de componentes clásicos en el núcleo, que ahora se han convertido al formato de archivo .gjs. (El nombre es confuso, lo sé 
)
El codemod que estamos ejecutando solo hace la conversión del formato de archivo de js/hbs a .gjs. No cambia el tipo de componente; eso sería casi imposible de automatizar perfectamente.
4 Me gusta
Suficiente, pero a menudo vale la pena hacer el esfuerzo si te encuentras en medio de una refactorización manual.
3 Me gusta
Dios mío. Justo cuando pensaba que estaba empezando a entender.
¡Así que no soy solo yo! 
¿Esto hace que sea un componente de Glimmer?
Y si ese es el caso; incluso si es solo una plantilla, ¿agregar la clase hace que se ejecute más rápido que si es un .gjs que solo tiene \u003ctemplate\u003eMis palabras importantes\u003c/template\u003e?
export default class MyCoolComponent extends Component {
1 me gusta
Es esto:
import Component from "@glimmer/component";
(y la conformidad posterior con las normas de Glimmer.
2 Me gusta
¡Ajá! Así que aún necesitarías declarar la clase para usar la parte del componente importado.
¡Muchas gracias!
3 Me gusta
Mi principal problema aquí es que en un hbs puedo simplemente hacer referencia a un componente de otro componente de tema ya que no necesito esa importación explícita. Pero en un gjs necesito importarlo y no tengo idea de cómo hacer referencia a un componente definido en otro componente de tema.
Todas las implementaciones existentes que he visto son a) todavía usan hbs o b) usan inyección basada en Javascript.
1 me gusta
En ese caso, obtengo esta recomendación de eslint:
Lo que sugiere es que solo debes agregar la clase cuando la necesites, ya que de lo contrario sería más lento.
1 me gusta
En orden ascendente de rendimiento:
-
Componente clásico:
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 de plantilla:
export default <template> ... </template>
exactamente
Actualmente, los temas no pueden importar de otros temas. El hecho de que fuera posible tener dependencias entre temas a través de la resolución mágica basada en nombres no fue realmente intencional
¿Podrías ampliar tu caso de uso, quizás en otro tema? No es algo que hayamos encontrado (todavía) para ninguno de nuestros propios temas.
3 Me gusta
Creo que sí… (bloques de barra lateral derecha).
La semana pasada, mi principal caso de uso fue forzar un orden para varios componentes de tema que utilizaban el mismo conector de plugin. Si bien los archivos CSS se cargan en orden alfabético, el JS de los componentes del tema se carga en orden numérico, así que terminé eliminando componentes del tema y volviéndolos a agregar en el orden que necesitaba, tratando de evitar al mismo tiempo todos los problemas de CSS que esto causaba.
Luego, se me ocurrió que podía simplemente eliminar el conector en cada uno de ellos y crear un nuevo componente de tema que tuviera esto en un solo conector para ese conector de plugin:
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
lo cual funciona muy bien. Y luego pensé: 'oh, necesito que esto sea un gjs para evitar tener que rehacer esto en unos meses. Y luego 
1 me gusta
Tienes un cliente que quería hacer esto al mudarse contigo. No recuerdo los detalles.
Acabo de hacer un fork de esto para un cliente actual que acaba de lanzar. Querían agregar un par de tipos de bloques más. Intenté tener un tema hermano que hiciera solo cosas de CSS, pero al final tuve que rendirme y hacer un fork. No estoy muy seguro de si podría haber habido otra manera.
1 me gusta
Pero…
2 Me gusta
Son excelentes noticias, excepto que no lo entendí antes. Recuerdo haber visto eso y también recuerdo haber discutido el problema y alguien sugirió que necesitaba bifurcar (fork), pero ahora estoy bastante seguro de que no es necesario.
Hmmm … Discourse Bars 🍻 🍸 (a sidebar framework) … usa el mismo sistema y no he tenido problemas.
El propósito de todo esto es que puedes usar Componentes de otros Componentes de Tema o Plugins (y funciona)
right-sidebar-blocks y discourse-tc-bars están utilizando el resolutor de Ember para buscar componentes por nombre. Por ahora, eso funciona y no está obsoleto.
En .hbs se hace como {{component "some-name"}}, y en (g)js se puede hacer como resolveRegistration("component:some-name").
Pero si hablamos a largo plazo, entonces deberíamos intentar evitar la búsqueda de componentes en el resolutor de Ember. Una vez que activemos la opción “invocables estáticos” de Embroider, el resolutor estará vacío.
Esta es la dirección que creo que debemos tomar para right-sidebar-blocks y otros componentes similares compartidos entre temas/plugins:
5 Me gusta