[MatRipple] Hover/Touch Event listeners are still added when ripples are disabled via a MAT_RIPPLE_GLOBAL_OPTIONS Provider

[justinappler]

Reproduction

https://stackblitz.com/edit/components-issue-asjy3a

Steps to reproduce:

1. Add a provider for MAT_RIPPLE_GLOBAL_OPTIONS that disabled ripples, e.g.

@Injectable({providedIn: 'root'})
export class AppGlobalRippleOptions implements RippleGlobalOptions {
  disabled: boolean = true;
}

2. Include a Material Component that uses MatRipple, but doesn't disable them via the component input (e.g. MatButton).

Expected Behavior

When Ripples are globally disabled, elements containing a MatRipple should not have event listeners attached to the target elements.

Actual Behavior

Even when Ripples are globally disabled via a MAT_RIPPLE_GLOBAL_OPTIONS Provider, elements with MatRipples will have six click/touch listeners attached. These listeners are not themselves problematic, but when many components are present on the page represent a significant performance hit.

It looks like the last work done on this was in #11865. I discovered this issue when trying to enable and disable ripples at runtime as described in the documentation (as a means to further improve initial page load performance (a surprising amount of time is consumed setting up these 6 event listeners per element).

Environment

• Angular: 7.2.3
• CDK/Material: 7.3.0
• Browser(s): n/a (All)
• Operating System (e.g. Windows, macOS, Ubuntu): n/a (All)

[devversion]

@justinappler Thanks for reporting that issue. I can see the point that setting up the event listeners is not needed if the ripples are globally disabled. At first glance I'm not sure if this is even achievable with the current API for disabling/enabling ripples globally.

Let's say you disable ripples globally on application bootstrap. In that case we would not setup any event listeners for ripple trigger elements. Now at runtime, the disabled property is set back to false, but we have no easy way to detect that the disabled property has changed. Therefore we can't register the events on the trigger element.

An ideal solution would be if we provide a service for the global options where developers can toggle the disabled state of ripples by calling a method/setter (so that we can react and setup/teardown events).

[justinappler]

It's certainly reasonable to have the listeners always be present as a side effect of having the ability to enable and disable ripples at runtime. The interesting thing is how much time is spent setting up those listeners on initial render (with many Material components on the page). Just wanted to make people aware.

[devversion]

We improved this slightly with fca0c28. Initially only two events are set up per ripple now. There is still room for improvement as explained in the commit message.

[jelbourn]

Closing since I don't think we'll be making any changes to this handling for now. As we continue to align with MDC web, our ripple handling/rendering will also evolve.