Aprecio a flexibilidade de ter a API completa do componente disponível. Gosto da sintaxe dos componentes Glimmer em geral, e vejo por que ela pode ter benefícios em reduzir a complexidade dentro da base de código.
No entanto, para casos de uso básicos (quero adicionar um botão e dar a ele um ícone), os métodos antigos da API eram objetivamente mais concisos e fáceis de entender (menos importações, menos operações, menos pegada de API exposta). Existe alguma razão pela qual os métodos antigos da API não poderiam ter suporte contínuo? Imagino que se você os usasse como funções de conveniência e realizasse a implementação subjacente usando seu novo componente Glimmer, o método da API também poderia realizar a verificação de compatibilidade de versão.
Isso seria muito menos disruptivo para qualquer pessoa que use esses métodos e criaria menos explosão de código de lógica condicional no ecossistema de plugins.
Minha principal reclamação sobre os widgets existentes é a falta de documentação. Este post, anunciando sua remoção, é um dos documentos mais claros que vi de que esses métodos específicos existem e como usá-los. Na verdade, vim aqui tentando descobrir como usar a API antiga.
Gosto que os transformadores sejam registrados em um só lugar, por literais de string. Acho que isso torna o trabalho de documentação (e desenvolvimento de plugins) muito mais fácil.
Com os widgets, todos parecem ser registrados pelo método createWidget, que então chama createWidgetFrom. O problema que vejo nisso é que o _registry é uma variável global de escopo de arquivo protegida por uma API, e a API não permite nenhuma iteração. Se pudéssemos apenas obter uma função de iteração no registro de widgets, poderíamos descobrir em tempo real os widgets atualmente registrados. Deveria ser documentado “execute esta linha de javascript no console do seu navegador para chamar a API e listar o registro”. Então, poderíamos obter uma utilidade muito semelhante à que o registro de transformadores está fornecendo.
Outra coisa que ajudaria no desenvolvimento de plugins é ver um atributo em qualquer elemento DOM raiz renderizado por um componente/widget que diga qual componente/widget você está olhando. Como “data-widget=foo”. Isso poderia ser um recurso de depuração, ou poderia simplesmente estar habilitado por padrão. É OSS, então não é como se você estivesse alcançando segurança por obscuridade.
Celebro a mudança para componentes Glimmer. Mas isso levará tempo, e há muitos widgets com os quais as pessoas precisam trabalhar nesse ínterim. Portanto, acho que melhorar a visibilidade dos widgets, como mencionado acima, provavelmente tornaria o período de transição mais fácil para todos.
Quanto a esses métodos de API… Parece que alguém se deu ao trabalho de adicionar comentários detalhados à API javascript, mas nenhum site de documentação foi gerado para isso. Por que não?
Ficarei feliz em enviar um pull request para iterar pelo registro de widgets, se isso for aceitável.