feat(dialog): Support updating MatDialogConfig from the dialog itself

[PowerKiKi]

Feature Description

MatDialogConfig has 32 properties and a lot of those could be allowed to be updated from within the dialog itself. Typically all visual aspects, such as width, height, classes, and ARIA attributes should be a no-brainer, but possibly much more than that. Below is the list of what I think could be possible.

A possible way to do this could be to introduced a signal based UpdatableMatDialogConfig that can be injected into the dialog. The dialog can change one of its property and the internals of MatDialog can react appropriately. So roughly something like that:

import {Component, inject, InjectionToken, type WritableSignal} from '@angular/core';

type UpdateableMatDialogConfig = {
    maxWidth: WritableSignal<number | string | undefined>;
    // etc...
};

const UPDATEABLE_CONFIG = new InjectionToken<UpdateableMatDialogConfig>('MatDialogConfig but can be updated');

@Component({
    //...
})
export class MyDialogComponent {
    readonly updateableConfig = inject(UPDATEABLE_CONFIG);

    constructor() {
        this.updateableConfig.maxWidth.set(400);
        // etc...
    }
}

Config	Could be updated from dialog
viewContainerRef	❌
injector	❌
id	✅ maybe ?
role	✅
panelClass	✅
hasBackdrop	❌
backdropClass	✅
disableClose	✅ already possible
closePredicate	✅
width	✅
height	✅
minWidth	✅
minHeight	✅
maxWidth	✅
maxHeight	✅
position	✅ maybe ?
data	❌
direction	✅
ariaDescribedBy	✅
ariaLabelledBy	✅
ariaLabel	✅
ariaModal	✅
autoFocus	✅
restoreFocus	✅
delayFocusTrap	❌
scrollStrategy	✅ maybe ?
closeOnNavigation	✅
enterAnimationDuration	❌
exitAnimationDuration	✅

Use Case

This would present two advantages over current situation.

First it centralizes things in the dialog itself, instead of repeating it at every call sites. So if I have a dialog that I want to be 400px wide and that is used in lots of different places in my code, I don't need to repeat 400px everywhere, or come up with a way to centralize things myself (which might or might not be very error-prone if not every developer is aware of that custom mechanic). With this new solution opening a dialog is heavily simplified in most common use-cases, and we don't need to worry about details such as "should I set a maxWidth ?".

Second, it allow encapsulation of internal logic that have nothing to do with the dialog caller. Typically closePredicate most likely include logic that is specific to the dialog. It makes no sense to expose the dialog internals only to be able to set closePredicate at caller site. Instead I want my dialog to be responsible of its own behavior. Again, this make opening the dialog much easier, without forcing us to open up our dialog internals.

@teolag mentioned that he does not want to expose his dialog internals in #14292 (comment). @robmv concurred in #14292 (comment). And @Nakira had to come up with a custom solution to solve this in #14292 (comment)

With this proposal, dialogs would be easier to re-use throughout the entire application with a consistent behavior/appearance and with minimal effort from developers.