feat: respect animation @.disabled binding

[devversion]

For custom CSS transitions we currently only check whether the NoopAnimationsModule is used or not. If noop animations are used, we apply a CSS class that can be used to set the transition or animation to none.

Since developers can toggle the animations dynamically through the [@.disabled] binding (which goes down the component tree), we should also respect this binding because such binding is commonly used.

Also instead of using a mixin that does magic, we should explicitly manage the selectors in order to keep the generated CSS as predictable and small as possible.

See https://angular.io/api/animations/trigger and #12812 (comment)

Note: Technically shouldn't be a breaking change. More a fix for developers using @.disabled.

[jelbourn]

LGTM

[crisbeto]

LGTM

[devversion]

Note: There are a few more components that use custom transitions but don't respect the NoopAnimationsModule at all. I will work on a follow-up PR that makes them consistent.

[ben-yocum]

Nice work. This will be very helpful to me.

When you talk about fixing "a few more components" in a later PR, which ones do you mean? For example, mat-menu does not respect [@.disabled] and has caused problems for my E2E tests.

[devversion]

@gitsage There are a few components which don't respect the NoopAnimationsModule at all.

With #12839, those components should be consistent with other components which already respect the NoopAnimationsModule. Also those will respect the [@.disabled] binding (like with this PR)

[ngbot]

Hi @devversion! This PR has merge conflicts due to recent upstream merges.
Please help to unblock it by resolving these conflicts. Thanks!

[ngbot]

Hi @devversion! This PR has merge conflicts due to recent upstream merges.
Please help to unblock it by resolving these conflicts. Thanks!

[ngbot]

Hi @devversion! This PR has merge conflicts due to recent upstream merges.
Please help to unblock it by resolving these conflicts. Thanks!

[ngbot]

Hi @devversion! This PR has merge conflicts due to recent upstream merges.
Please help to unblock it by resolving these conflicts. Thanks!

[devversion]

@jelbourn This never got merged and now has a lot of conflicts. do you think it's worth rebasing this?

I don't think it is a priority, but maybe rather something we need to be aware of when creating the MDC protoypes?

[mmalerba]

Yeah we should make sure to do this for the MDC-based components, should be easy since they're still in experimental. If you're going to rebase this one I would suggest splitting it into separate PRs per component

[devversion]

@mmalerba 👍 Regarding rebasing this PR: I'm not sure it's worth doing that as it probably requires a new audit to look for new instances that need to be updated.

[jelbourn]

Yeah, at this point I think we can skip this change and ensure we set things up property for the MDC components. One thought there, though, is that we support more granular animation options instead of it being all or nothing. I've heard from some users that they want to e.g. disable animations for menus, but not for progress-bar/spinner

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