Skip to content

perf(tooltip): Defer hooking up events until there's a message and the tooltip is not disabled #19764

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

Merged
merged 2 commits into from
Jul 14, 2020

Conversation

kseamon
Copy link
Collaborator

@kseamon kseamon commented Jun 25, 2020

No description provided.

@kseamon kseamon requested a review from andrewseguin as a code owner June 25, 2020 20:19
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Jun 25, 2020
@@ -543,6 +550,12 @@ export class MatTooltip implements OnDestroy, AfterViewInit {

/** Binds the pointer events to the tooltip trigger. */
private _setupPointerEvents() {
// Optimization: Defer hooking up events if there's no message or the tooltip is disabled.
if (this._disabled || !this.message || !this._viewInitialized ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this check should be at the call site, rather than inside setupPointEvents, otherwise the caller has no way of knowing that the events were actually bound. We can pull out this logic into a utility method if it needs to be checked in multiple places.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's safer to be here - otherwise it could accidentally be omitted. Would adding a return boolean value here be ok for if the caller needs to know?

Alternatively, they can just check this._passiveListeners.size

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a private API so we can probably get away with not returning what the result was. Let's keep it like this for now and we can rework it if it becomes an issue.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this behavior with the names in your follow-up PR

@@ -276,6 +282,7 @@ export class MatTooltip implements OnDestroy, AfterViewInit {

ngAfterViewInit() {
// This needs to happen after view init so the initial values for all inputs have been set.
this._viewInitialized = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the only case where this would help is if the message changes quickly before ngAfterViewInit has fired, but I don't know if that's actually possible, or if it is, it's very unlikely. In theory it can happen if people were to go directly through the setter, but they'd have to do it inside a constructor for it to matter.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to be safe, right?

Copy link
Member

@crisbeto crisbeto Jun 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it's overly-protective since people would have to actively go out of their way to make it behave differently, and even if it does, it won't actually break, it'll just bind some events before they're actually needed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was there a reason that it hooked up in ngAfterViewInit before? My concern was that adding the call to the message and disabled setters would cause the events to be attached earlier than they were before without this check.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's a specific reason for it. My guess is that we had the lifecycle hook defined already so we reused it instead of adding another one.

@jelbourn jelbourn added G This is is related to a Google internal issue target: patch This PR is targeted for the next patch release P2 The issue is important to a large percentage of users, with a workaround labels Jun 26, 2020
Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, the comment about message could be resolved here or in the follow-up PR

@@ -202,14 +205,17 @@ export class MatTooltip implements OnDestroy, AfterViewInit {
@Input('matTooltip')
get message() { return this._message; }
set message(value: string) {
this._ariaDescriber.removeDescription(this._elementRef.nativeElement, this._message);
if (this._message) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than checking message here, could AriaDescriber just check this and no-op immediately?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updating in #19777

@@ -543,6 +550,12 @@ export class MatTooltip implements OnDestroy, AfterViewInit {

/** Binds the pointer events to the tooltip trigger. */
private _setupPointerEvents() {
// Optimization: Defer hooking up events if there's no message or the tooltip is disabled.
if (this._disabled || !this.message || !this._viewInitialized ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this behavior with the names in your follow-up PR

@jelbourn jelbourn added lgtm action: merge The PR is ready for merge by the caretaker labels Jun 26, 2020
@andrewseguin andrewseguin merged commit 49de56c into angular:master Jul 14, 2020
andrewseguin pushed a commit that referenced this pull request Jul 14, 2020
…e tooltip is not disabled (#19764)

* perf(tooltip): Defer hooking up events until there's a message and the tooltip is not disabled

* comment update
andy9775 pushed a commit to andy9775/components that referenced this pull request Jul 16, 2020
…e tooltip is not disabled (angular#19764)

* perf(tooltip): Defer hooking up events until there's a message and the tooltip is not disabled

* comment update
ngwattcos pushed a commit to ngwattcos/components that referenced this pull request Jul 20, 2020
…e tooltip is not disabled (angular#19764)

* perf(tooltip): Defer hooking up events until there's a message and the tooltip is not disabled

* comment update
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Aug 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement G This is is related to a Google internal issue P2 The issue is important to a large percentage of users, with a workaround target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants