chore(api): overlay class audits #6372

[amcdnl]

This PR does the following:

• Adds a new utility method for parsing string|string[]|{key/value} to ngClass-like object
• Adds a new utility method for parsing a ngClass-like object to string array
• Updates overlay implementation to accept ngClass-like object
• Adds panelClass to date picker
• Deprecates extraClasses to panelClass in snackbar
• Deprecates class input to panelClass and accepts ngClass-like object in menu
• Updates dialog implementation to ngClass like object

I really didn't like the fact I had to add this to the CDK. I originally had it as a utility inside material but the overlay lives in the CDK and needed it there too. @jelbourn - do you have any thoughts on better place for this?

This is still very WIP.

[crisbeto]

I'm sure that we need to support all of these formats. NgClass has them, presumably, because the expressions are dynamic and there a lot of ways to combine static classes and dynamic ones. In our case we only add the classes on init and we don't care about updating them, which can be done just as easily with an array.

[amcdnl]

The original ticket expressed desire to standardize this format. Ref: #6372

[willshowell]

FWIW NgClass seemed like a natural thing to support for template-based overlays like select, menu, autocomplete, tooltip. For dialog and snackbar, it's probably less important, but there are some good use cases for having the ability to dynamically update classes, #6206 (comment).

Further, I would personally find an NgClass cdk utility useful for custom overlay-based components!

[crisbeto]

Template-based overlays should "just work" as they are at the moment (you can stick an NgClass on an element inside the TemplateRef). This PR adds a similar signature to the programmatic API, but it's not really NgClass because it won't update dynamically.

[willshowell]

Ok tbh, I hadn't actually read the pr 😄 . My initial concern in filing #6372 was how snackbar and dialog differed in support and naming. Combined with little type info available in the docs (as #6947 is trying to solve) it's hard to anticipate exactly what will happen just by looking at the docs.

I agree, {[klass: string]: any} is probably extraneous (and maybe misrepresenting) if classes don't update dynamically. While I still think that's a valid feature via #6206, maybe for another time.

[amcdnl]

Ya, so basically this PR:

• Unifies all the css class names to panelClass
• Normalizes all the signatures to ngClass-like

That means you can pass it an string, string array or object key/value pair. In the cases of the snackbar and overlay, there is no ngClass used so it just does a evaluate of the condition and matches it. I personally think the consistent signature is valuable and in the situation where there isn't real ngClass I could do an actual implementation I just didn't do it because I didn't know how far we wanted to take this.

@jelbourn - Can you advise on next steps with this? Currently the PR is just in a evaluation phase and I know you expressed concerns with adding another CDK lib here too so I didn't want to take it too far without first review.

[amcdnl]

Closing in favor of #8056

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