refactor(dialog): remove deprecated APIs for 9.0.0

[crisbeto]

Removes the APIs that were scheduled to be removed from the dialog package in v9.

BREAKING CHANGES:

• MatDialogRef.afterOpen has been replaced with MatDialogRef.afterOpened.
• MatDialogRef.beforeClose has been replaced with MatDialogRef.beforeClosed.
• MatDialog.afterOpen has been replaced with MatDialog.afterOpened.
• matDialogAnimations.slideDialog has been replaced with matDialogAnimations.dialogContainer.
• _location parameter in MatDialogRef constructor has been removed.

[jelbourn]

LGTM

[jelbourn]

Looks like it just needs API golds updated

[jelbourn]

Breaks nearly 2,000 targets in Google. We'll need to dedicate more time to updating people.

[mmalerba]

Though there were many broken targets, the underlying cause was only about 20 or so files, working on updating them now

[deviantpixel]

@crisbeto @jelbourn Can I ask why Location features are being stripped out? I noticed the comment saying they are being deprecated. Is this because of a dependency deprecation or just a decision to deprecate the feature of monitoring the paths to trigger a dialog close?

I ask because I am investigating ways of solving an issue where the dialog remains open during routing changes and ways to allow a feature to "auto-close" the dialog when a routing change occurs. The current "Location" based features is a small part of this and I would be expanding it to use the Router most likely to expand this feature.

Let me know as the information is helpful to know if I should be building this as a solution to be contributed here.

[crisbeto]

These changes remove the _location constructor parameter from MatDialogRef. It hasn't been used for anything for a while now, we just had to wait for a major version to remove it.

[deviantpixel]

Any interest in an addition that allows for Routing changes to auto-close the Dialog? I would assume it would be an opt-in flag to avoid regression issues. If so I can work on it to contribute it. If this goes against the Dialog assumed features no problem at all.

[crisbeto]

We haven't added closing based on routing, because it would introduce a dependency between Material and the router.

[jelbourn]

Dialog has a closeOnNavigation option, though, which closes based on the location changing. This used to be implemented in the dialog, but it moved to the lower-level overlay (which is why it's being removed from dialog here)

[deviantpixel]

Got ya. Makes sense and I did discover that layer. The only issue is I believe that using Location observing which only emits for back/forward browser actions as opposed to clicking links/buttons or other path changes. It's helpful but doesn't cover things like a link in a dialog going to another route in the app or in our case a redirect/auto logout that triggers a route change while the dialog may be open.

Definitely understandable about the Route dependency. I can build it in as a one-off for our implementation. Ping me if there is interest in including this in the future. I will also see if there are ways to do this without needing the Route dependency ;)

[angular-automatic-lock-bot]

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.}