I appreciate the flexibility of having the full component API available. I like the syntax of glimmer components overall, and I see why it may have benefits in reducing complexity within the codebase.
However, for basic use cases (I want to add a button and give it an icon), the old API methods were objectively more terse and easy to understand (less imports, less operations, less API footprint exposed). Is there any reason why the old API methods could not enjoy continued support? I’m imagining if you used them as convenience functions and performed the underlying implementation using your new glimmer component, then the API method could also perform the version compatibility check.
This would be far less disruptive to anyone using these methods, and would create less of a code explosion of conditional logic within the plugin ecosystem.
My main complaint about the existing widgets is their lack of documentation. This post, announcing their removal, is one of the clearest documents I have seen that these particular methods exist and how to use them. I came here in fact, trying to figure out how to use the old API.
I like that transformers are registered in one place, by string literals. I think that makes the documentation (and plugin development) job a whole lot easier.
With widgets, they all seem to be registered by the createWidget method, which then calls createWidgetFrom. The issue I see with this is that the _registry is a file scope global variable protected by an API, and the API doesn’t allow any iteration. If we could just get an iteration function on the widget registry, then we could discover in real time the currently registered widgets. It should be documented “run this line of javascript in your browser console to call the API and list the registry”. Then we could get a very similar utility to what the transformer registry is providing.
Another thing that would help in plugin development is to see an attribute on any root DOM element rendered by a component/widget which tells you what component/widget you are looking at. Like “data-widget=foo” This could be a debug feature, or it could just be enabled by default. It’s OSS, so it’s not like you’re achieving security through obscurity.
I celebrate the shift towards glimmer components. But this will take time, and there’s a lot of widgets that people need to work with in the meantime. So I think improving the visibility of widgets as mentioned above would likely make the transition period easier for everyone.
As for those API methods… It looks like someone went to the trouble to add detailed comments to the javascript API, but no documentation site was ever generated for it. Why not?
I’d be happy to submit a pull request for iterating through the widget registry, if that’s agreeable.