feat(mat-button): add progress-spinner option

Bug, feature request, or proposal:

Proposal

What is the expected behavior?

Allow for a properly-sized and positioned progress spinner to be triggered inside a mat-button, temporarily overriding its initial content

What is the current behavior?

No configuration available, can manually place and position a progress spinner inside a mat-button

What are the steps to reproduce?

This is a sample template thrown together (very unoptimized): https://stackblitz.com/edit/angular-material2-issue-qbjrmi?file=app%2Fapp.component.html

Click on LOADING to trigger the spinner

What is the use-case or motivation for changing an existing behavior?

Defined in the spec: https://material.io/design/components/progress-indicators.html#circular-progress-indicators under “Integrating with actions”

Is there anything else we should know?

Probably needs an a11y review since the content of the button will change

[CaerusKaru]

Discussed with @crisbeto offline, and we’ve come up with two options:

• We’ll introduce a mat-progress-container, but its purpose is to center content inside another container element like mat-button or mat-menu
• We’ll also introduce a matProgress directive that sits on the container (ie the mat-button or mat-menu) to set position: relative and necessary ARIA attributes based on a boolean trigger

Here’s where the ideas diverge:

1. In the first idea, we leave the rest to the user, likely to use this template:

<button mat-raised-button [matProgress]="trigger">
  <mat-progress-container *ngIf="trigger; else content">...</mat-progress-container>
  <ng-template #content>Upload</ng-template>
</button>

1. In the second idea, the burden of templating is on us. IMO this makes for a much nicer UX, but complicates the code a bit

<button mat-raised-button [matProgress]="trigger">
  <mat-progress-container>...</mat-progress-container>
  <mat-progress-content>Upload</mat-progress-content>
</button>

This not only provides a clear differentiation between the progress and the content, it also reduces the redundancy and possibility for failure by removing the dual trigger uses. Here, the progress-container is responsible for marshaling content inside the button/menu, replacing the content based on the value of the host’s progress directive.

The only issues with both approaches are a) the best way to handle a11y, and b) the best way to swap content while maintaining size concerns (i.e. making sure the container height stays the same)

[arknu]

How come this is still not implemented? Is is specifically stated in the Material Design guidelines that you should “Use circular indicators for short, indeterminate activities (< 5 seconds) requiring user attention.” (https://material.io/components/progress-indicators#circular-progress-indicators) - i.e. anything that requires a trip to the server when clicking the button. If this library is supposed to follow the Material Design guidelines, this feature needs to be implemented. I know you can do it manually, but this really is something that I would expect a library like Angular Material to just take care of. Of the proposed APIs by @CaerusKaru, I’d definitely prefer option 2. I don’t think you should have to manually do *ngIf and templates to make this feature work.