-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(telemetry): telemetry improvements VSCODE-673 #914
Conversation
}); | ||
|
||
if (!event.element.onDidExpand) { | ||
if (!treeItem.onDidExpand) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do I understand correctly that if we do not have an onDidExpand
set then we also don't end up calling _onTreeItemUpdate
? Seems to be the legacy behavior so not an issue for this PR, more of not sure why this is fully returning here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems to be the case - I don't know if this is incorrect and a lurking bug or there's a deeper meaning to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this part handles three elements that don't have children. I might be mistaken, maybe Rhys knows better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just minor non-blocking comment
/** | ||
* Reported when a tree item from the collection explorer is expanded. | ||
*/ | ||
export class TreeItemExpandedTelemetryEvent implements TelemetryEventBase { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
though here this seems better as section is too vague... which maybe says more about the name of the type.
I don't mind leaving it as is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd prefer to leave this as - I know there's a discrepancy between the class name and the event name, but I feel it's fine as those are intended to be consumed by different audiences.
|
||
export default class HelpExplorer { | ||
_treeController: HelpTree; | ||
_treeView?: vscode.TreeView<vscode.TreeItem>; | ||
|
||
constructor() { | ||
constructor(private _telemetryService: TelemetryService) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need _telemetryService
in the constructor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is meant to be a shortcut for passing it as an argument in the constructor and defining/setting it as a property of the class object which is then used in its method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to inject the telemetry service and I think it's better to do it via the ctor rather than as an argument to activateHelpTreeView
like it was previously. I think that way is cleaner architecturally as I see it as a dependency we set once for the lifetime of the controller. Obviously, there's not a huge difference with the HelpExplorer
because it's a fairly minimalistic class, but if you consider a more complex controller that has multiple methods which need to log some telemetry events, it becomes much easier to reason about how the dependencies are satisfied.
|
||
export default class PlaygroundsExplorer { | ||
private _treeController: PlaygroundsTree; | ||
private _treeView?: vscode.TreeView<vscode.TreeItem>; | ||
|
||
constructor() { | ||
constructor(private _telemetryService: TelemetryService) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. Doesn't seem we use _telemetryService
in the constructor.
* Reported when a tree item from the collection explorer is expanded. | ||
*/ | ||
export class TreeItemExpandedTelemetryEvent implements TelemetryEventBase { | ||
type = 'Section Expanded'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is Section
a tree item? If yes, maybe Tree Item Expanded
would be more transparent than Section Expanded
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was the name Amanda suggested and I am inclined to keep it because the fact those are tree items is an implementation detail of the code and not terminology that non-engineers necessarily use when describing the connection tree.
@@ -189,4 +191,12 @@ export class TelemetryService { | |||
new ParticipantResponseFailedTelemetryEvent(command, errorName, errorCode) | |||
); | |||
} | |||
|
|||
trackTreeViewActivated: () => void = throttle( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why to we want to throttle here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to the way the extension works, there's no integration point we can use to be notified that the side panel is opened, which is why we're piggy-backing on the tree visibility event. However, since we have 3 trees in the side panel (connections, playgrounds, help), that event would get fired 3 times every time we open the sidepanel. Rather than deal with this in post-processing, I figured throttling would be a reasonable way to reduce the noise.
Description
This addresses the requested improvements tracked in this document.
Side Panel Opened
event when the extension side panel is activatedSection Expanded
event when a section is expanded in the connections tree viewUpdateCommand Run
withsource: command_bar | shortcut
Playground Code Executed
to include the type of the command when it'sother
UpdatePlayground Created
, addsource_details
Motivation and Context
Types of changes