Open WidgetInspectorService APIs to use by package/devtools extensions authors #8519
Labels
devtools extensions
Issues related to DevTools extensions
P2
important to work on, but not at the top of the work list.
screen: inspector
Use case
My team and I are building a new package and devtools extension, that would highly benefit from the ability to tell which widget from the local project corresponds to a specific coordinate on screen - exactly like the WidgetInspector does with the "Select Widget" feature.
My first thought was to learn how it's implemented in WidgetInspector and try to tap into the same APIs, but I quickly learned that those APIs clearly were not meant to be called from the "outside", and while I was able to work my way around their limitations, it's very hacky and definitely not the intended way to do it.
The issue I'm facing is that most of the
WidgetInspectorService
methods are either private or protected. The class is designed in such a way, that a lot of methods that return some useful data are private and have their protected counterpart that converts their return value into JSON for transfer to devtools. For example:and
And if we assume that the devtools is the only consumer of that data, then it's perfectly understandable why it was designed that way. But since it's all protected or private, there's no "right" way for external packages to check whether a specific widget was created by local project.
I think it basically comes down to a single small method within
WidgetInspectorService
, that allows for checking the object creation location:And since the
_HasCreationLocation
class doesn't seem to be explicitly used anywhere else I can only assume that it is somehow dynamically added to objects by the engine in runtime.Proposal
My proposal is to either open up the
WidgetInspectorService
APIs to allow package authors to tap into the methods it provides, or even just allow the_HasCreationLocation
class to be used outside of the WidgetInspector environment by making it public.I'm aware this is a rather niche feature request that wouldn't be used by many developers, but if there's no significant arguments against it, I'd be happy to prepare a PR with a proposal of how the updated API could look like.
The text was updated successfully, but these errors were encountered: