我赞赏拥有完整组件 API 的灵活性。我喜欢 Glimmer 组件的整体语法，并且我明白它可能在降低代码库复杂性方面具有优势。
但是，对于基本用例（我想添加一个按钮并为其添加图标），旧的 API 方法在客观上更简洁易懂（导入更少，操作更少，暴露的 API 占用空间更小）。旧的 API 方法是否有任何理由不能继续支持？我想象如果将它们用作便捷函数，并使用新的 Glimmer 组件执行底层实现，那么 API 方法也可以执行版本兼容性检查。
这将对使用这些方法的任何人造成的干扰要小得多，并且可以减少插件生态系统中条件逻辑的代码爆炸。
我对现有组件的主要抱怨是它们缺乏文档。这篇宣布移除它们的帖子是我见过的关于这些特定方法存在以及如何使用它们的 सर्वात清晰的文档之一。事实上，我来这里是为了弄清楚如何使用旧的 API。
我喜欢转换器在一个地方，通过字符串字面量进行注册。我认为这使得文档（和插件开发）工作变得容易得多。
对于组件，它们似乎都通过 createWidget 方法注册，该方法然后调用 createWidgetFrom。我在这里看到的问题是，_注册表是一个文件作用域的全局变量，由一个 API 保护，而该 API 不允许任何迭代。如果我们能在组件注册表中获得一个迭代函数，那么我们就可以实时发现当前注册的组件。应该记录“在浏览器控制台中运行此行 JavaScript 来调用 API 并列出注册表”。然后，我们可以获得与 transformer 注册表提供的功能非常相似的功能。
在插件开发方面，另一件有帮助的事情是，在组件/组件渲染的任何根 DOM 元素上看到一个属性，告诉我们您正在查看哪个组件/组件。例如“data-widget=foo”。这可以是一个调试功能，也可以默认启用。它是开源的，所以您并不是通过隐藏来实现安全性。
我赞扬向 Glimmer 组件的转变。但这需要时间，在此期间，人们需要处理很多组件。因此，我认为如上所述改进组件的可视性可能会让每个人都更容易过渡。
至于那些 API 方法……看起来有人费尽心思为 JavaScript API 添加了详细的注释，但从未为此生成文档站点。为什么不呢？
如果可行，我很乐意提交一个用于迭代组件注册表的拉取请求。