Aprecio la flexibilidad de tener disponible la API completa del componente. Me gusta la sintaxis de los componentes de Glimmer en general, y veo por qué puede tener beneficios para reducir la complejidad dentro de la base de código.
Sin embargo, para casos de uso básicos (quiero agregar un botón y darle un ícono), los métodos de la API antigua eran objetivamente más concisos y fáciles de entender (menos importaciones, menos operaciones, menos huella de API expuesta). ¿Hay alguna razón por la que los métodos de la API antigua no pudieran tener soporte continuo? Me imagino que si los usara como funciones de conveniencia y realizara la implementación subyacente utilizando su nuevo componente Glimmer, entonces el método de la API también podría realizar la verificación de compatibilidad de versiones.
Esto sería mucho menos disruptivo para cualquiera que use estos métodos y crearía menos explosión de código de lógica condicional dentro del ecosistema de complementos.
Mi principal queja sobre los widgets existentes es su falta de documentación. Esta publicación, que anuncia su eliminación, es uno de los documentos más claros que he visto de que existen estos métodos particulares y cómo usarlos. De hecho, vine aquí tratando de descubrir cómo usar la API antigua.
Me gusta que los transformadores se registren en un solo lugar, mediante literales de cadena. Creo que eso facilita mucho el trabajo de documentación (y desarrollo de complementos).
Con los widgets, todos parecen registrarse mediante el método createWidget, que luego llama a createWidgetFrom. El problema que veo con esto es que el _registro es una variable global a nivel de archivo protegida por una API, y la API no permite ninguna iteración. Si pudiéramos obtener una función de iteración en el registro de widgets, podríamos descubrir en tiempo real los widgets registrados actualmente. Debería documentarse “ejecute esta línea de javascript en la consola de su navegador para llamar a la API y listar el registro”. Luego podríamos obtener una utilidad muy similar a la que proporciona el registro de transformadores.
Otra cosa que ayudaría en el desarrollo de complementos es ver un atributo en cualquier elemento DOM raíz renderizado por un componente/widget que le indique qué componente/widget está viendo. Como “data-widget=foo”. Esta podría ser una característica de depuración, o podría estar habilitada por defecto. Es OSS, por lo que no es como si estuviera logrando seguridad a través de la ofuscación.
Celebro el cambio hacia los componentes de Glimmer. Pero esto llevará tiempo, y hay muchos widgets con los que la gente necesita trabajar mientras tanto. Por lo tanto, creo que mejorar la visibilidad de los widgets, como se mencionó anteriormente, probablemente haría que el período de transición fuera más fácil para todos.
En cuanto a esos métodos de API… Parece que alguien se tomó la molestia de agregar comentarios detallados a la API de javascript, pero nunca se generó un sitio de documentación para ella. ¿Por qué no?
Estaría feliz de enviar una solicitud de extracción para iterar a través del registro de widgets, si eso es aceptable.