Skip to content
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

perf(ripple): do not register events if ripples are disabled initially #8882

Conversation

devversion
Copy link
Member

  • No longer registers trigger event listeners if the ripples are disabled initially.

Fixes #8854.

@devversion devversion added perf This issue is related to performance pr: needs review labels Dec 8, 2017
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Dec 8, 2017
// The events for a trigger element shouldn't be registered if ripples are disabled.
// As soon as the ripples are enabled again, the events for the current trigger will be added.
if (!this.disabled && this._isInitialized) {
this._rippleRenderer.setTriggerElement(trigger);
Copy link
Member

Choose a reason for hiding this comment

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

It feels strange to call setTriggerElement when you really just want one of the side-effects of setTriggerElement. Would it be easier to follow if there was a function to specifically add/remove the event listeners?

Copy link
Member Author

@devversion devversion Dec 8, 2017

Choose a reason for hiding this comment

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

What do you mean with side-effects? Maybe the function name is just not good and it should be called registerTriggerEvents() or something like that?

Copy link
Member

Choose a reason for hiding this comment

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

Based on the name, the primary purpose of setTriggerElement would be the line

 this._triggerElement = element;

The event stuff is incidental to updating the trigger element. It be a bit better as something like

  /** Sets the trigger element and registers the mouse events. */
  setTriggerElement(element: HTMLElement | null) {
    if (this._triggerElement === element) {
      return;
    }

    this._removeTriggerListeners();
    this._triggerElement = element;
    this._addTriggerListeners();
  }

Then other call site that don't need to update to a new element just call _removeTriggerListeners and _addTriggerListeners

Copy link
Member Author

Choose a reason for hiding this comment

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

I see what you mean, but the actual event registration should be the primary purpose of this function (or part in the RippleRenderer)

In that case I would just call the method _setupTriggerEvents() and keep the implementation as it is. The _triggerElement variable is just there for the event un-registration, and the real trigger element is stored in the MatRipple class. Does that work for you?

Copy link
Member

Choose a reason for hiding this comment

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

Agreed that at least the naming should change to something involving "events".

@@ -229,6 +228,7 @@ export class MatTabLink extends _MatTabLinkMixinBase
// Manually create a ripple instance that uses the tab link element as trigger element.
// Notice that the lifecycle hooks for the ripple config won't be called anymore.
this._tabLinkRipple = new MatRipple(_elementRef, ngZone, platform, globalOptions);
this._tabLinkRipple.ngOnInit();
Copy link
Member

Choose a reason for hiding this comment

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

It feels weird having to call the Angular lifecycle hook manually. Shouldn't the renderer support attaching to arbitrary elements?

// because the events should be only registered if the ripples aren't disabled initially.
// Also if there is no trigger element, that has been specified explicitly through the input,
// the default trigger element will be the directive's host element.
this.trigger = this._trigger === undefined ? this._hostElement : this.trigger;
Copy link
Member

@crisbeto crisbeto Dec 8, 2017

Choose a reason for hiding this comment

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

Doing this just so the setter runs is somewhat side-effect-ey. Why not have a private method that does the attachment both here and insider the setter?

// The events for a trigger element shouldn't be registered if ripples are disabled.
// As soon as the ripples are enabled again, the events for the current trigger will be added.
if (!this.disabled && this._isInitialized) {
this._rippleRenderer.setTriggerElement(trigger);
Copy link
Member

Choose a reason for hiding this comment

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

Agreed that at least the naming should change to something involving "events".

@devversion devversion force-pushed the perf/ripple-events-register-initial-disabled branch 5 times, most recently from 2f972c6 to 75a5fe0 Compare December 9, 2017 13:49
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

@jelbourn
Copy link
Member

@devversion just needs rebase whenever you have time

@devversion devversion force-pushed the perf/ripple-events-register-initial-disabled branch from 75a5fe0 to 30fbd9e Compare December 20, 2017 10:49
@devversion devversion added target: patch This PR is targeted for the next patch release and removed pr: needs rebase labels Dec 20, 2017
* No longer registers trigger event listeners if the ripples are disabled initially.

Fixes angular#8854.
@devversion devversion force-pushed the perf/ripple-events-register-initial-disabled branch from 30fbd9e to 270b974 Compare December 31, 2017 11:17
@devversion devversion added the action: merge The PR is ready for merge by the caretaker label Jan 2, 2018
@jelbourn jelbourn merged commit 58b93dc into angular:master Jan 4, 2018
@devversion devversion deleted the perf/ripple-events-register-initial-disabled branch January 7, 2018 08:53
jelbourn pushed a commit to jelbourn/components that referenced this pull request Jan 8, 2018
jelbourn pushed a commit to jelbourn/components that referenced this pull request Jan 9, 2018
@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 Sep 8, 2019
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 perf This issue is related to performance target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[MatCheckbox] nested ripple registers events even if disableRipple is set.
4 participants