Join GitHub today
Provide treeView service API #1162
Description of the Change
Provided a service that lets other packages consume the treeView instance.
At the moment any package that interacts with the tree-view package to get selected files or other information are doing so by getting the active package's
There is a standard way to get this information through the Services API
We may want to change what actually get provided if there are unstable features in the tree-view module.
Other packages can interact with this package in a standard way.
Here is an example of why this would be useful:
to get the treeView instance. This poses two problems:
Thanks for the contribution! I do however have concerns. Your proposition exposes the entire tree-view instance, which does not feel like an appropriate solution. The only justification I can think of is that it's the easiest approach with the least amount of effort. Keep in mind that most (if not all) of the tree-view object consists of private methods.
I propose that we expose an actual API, instead of simply handing developers an entire object, which essentially has no lifetime guarantees etc. For instance, if someone relies on this object, and the tree-view package is disabled, what do you think/expect will happen?
To begin with, which aspects of the tree-view do you think we have to expose? Let's begin with the bare minimum of features that are actually needed by external packages rights now — YAGNI™ and so on.
I agree, exposing the entire tree-view instance is probably not the right way to start out.
There are already some methods in tree-view class that are marked public. I'm assuming those are supposed to be public to the rest of the package. Those seem unlikely to change in any major way.
The most common thing other packages seem to do is get the selected paths. If we wanted to start really small we should start with that.
OK, that sounds like a reasonable approach