J’apprécie la flexibilité d’avoir l’API complète des composants disponible. J’aime la syntaxe des composants Glimmer dans l’ensemble, et je vois pourquoi cela pourrait présenter des avantages pour réduire la complexité du code.
Cependant, pour des cas d’utilisation simples (je veux ajouter un bouton et lui donner une icône), les anciennes méthodes d’API étaient objectivement plus concises et faciles à comprendre (moins d’importations, moins d’opérations, moins d’empreinte API exposée). Y a-t-il une raison pour laquelle les anciennes méthodes d’API ne pourraient pas continuer à être prises en charge ? J’imagine que si vous les utilisiez comme fonctions de commodité et que vous effectuiez l’implémentation sous-jacente à l’aide de votre nouveau composant Glimmer, la méthode d’API pourrait également effectuer la vérification de compatibilité des versions.
Cela serait beaucoup moins perturbateur pour quiconque utilise ces méthodes et créerait moins d’explosion de code de logique conditionnelle au sein de l’écosystème des plugins.
Ma principale plainte concernant les widgets existants est leur manque de documentation. Ce post, annonçant leur suppression, est l’un des documents les plus clairs que j’ai vus indiquant que ces méthodes particulières existent et comment les utiliser. Je suis venu ici en fait, en essayant de comprendre comment utiliser l’ancienne API.
J’aime que les transformateurs soient enregistrés en un seul endroit, par des littéraux de chaîne. Je pense que cela facilite grandement la documentation (et le développement de plugins).
Avec les widgets, ils semblent tous être enregistrés par la méthode createWidget, qui appelle ensuite createWidgetFrom (discourse/app/assets/javascripts/discourse/app/widgets/widget.js at a86590ffd6069a939d58002050ef0e9b92889a2e · discourse/discourse · GitHub). Le problème que je vois avec cela est que le _registry est une variable globale de portée de fichier protégée par une API, et l’API ne permet aucune itération. Si nous pouvions simplement obtenir une fonction d’itération sur le registre des widgets, nous pourrions découvrir en temps réel les widgets actuellement enregistrés. Il devrait être documenté “exécutez cette ligne de javascript dans la console de votre navigateur pour appeler l’API et lister le registre”. Ensuite, nous pourrions obtenir une utilité très similaire à ce que fournit le registre des transformateurs.
Une autre chose qui aiderait dans le développement de plugins est de voir un attribut sur tout élément DOM racine rendu par un composant/widget qui vous indique quel composant/widget vous regardez. Comme “data-widget=foo”. Cela pourrait être une fonctionnalité de débogage, ou cela pourrait simplement être activé par défaut. C’est de l’OSS, donc ce n’est pas comme si vous obteniez la sécurité par l’obscurité.
Je célèbre le passage aux composants Glimmer. Mais cela prendra du temps, et il y a beaucoup de widgets avec lesquels les gens doivent travailler entre-temps. Je pense donc qu’améliorer la visibilité des widgets, comme mentionné ci-dessus, rendrait probablement la période de transition plus facile pour tout le monde.
Quant à ces méthodes d’API… Il semble que quelqu’un ait pris la peine d’ajouter des commentaires détaillés à l’API javascript, mais aucun site de documentation n’a jamais été généré pour cela. Pourquoi pas ?
Je serais heureux de soumettre une pull request pour itérer sur le registre des widgets, si cela est acceptable.