Какова цель Угловой анимации?

Некоторое время я задавался вопросом, почему я должен использовать Angular анимацию для анимации CSS. Я вижу несколько областей, которые можно было бы рассмотреть перед их использованием:

Спектакль

На первом этапе я нашел этот вопрос, который имеет дело только с перцептивной стороной вещей. Принятый ответ мне не подходит, потому что он утверждает, что везде, где это возможно, следует использовать анимацию CSS, чтобы можно было использовать такие оптимизации, как запуск анимации в отдельном потоке. Это, похоже, не так, потому что Угловая документация

Угловая анимация построена поверх стандартного API веб-анимаций и запускается на основе браузеров, которые ее поддерживают.

(акцент мой)

И когда мы смотрим проект API веб-анимаций, мы видим, что те же самые оптимизации могут применяться к веб-анимации, как к CSS, указанному в листах.

Хотя можно использовать ECMAScript для выполнения анимации с использованием requestAnimationFrame [HTML], такие анимации ведут себя по-разному с декларативной анимацией с точки зрения того, как они представлены в каскаде CSS и возможностях оптимизации производительности, таких как выполнение анимации в отдельном потоке, Используя интерфейс программирования Web Animations, можно создавать анимации из сценария, которые имеют те же характеристики поведения и производительности, что и декларативные анимации.

(снова акцент мой)

Помимо некоторых браузеров, таких как IE, не поддерживаются веб-анимации, есть ли какая-либо причина использовать объявления CSS над угловыми анимациями или наоборот? Я рассматриваю их как взаимозаменяемые.

Больше контроля над анимацией

Это может выглядеть как аргумент для угловых анимаций, потому что вы можете приостановить анимацию или использовать переменные JS с ней и т.д., Но то же самое верно при использовании, например. CSS- animation-play-state: pause или использовать переменные CSS, указанные в JS, см. Документацию.

Теперь я вижу, что было бы неудобно устанавливать переменные CSS в JS-коде, но то же самое верно при использовании Angular animations. Они обычно объявляются в @Component animations @Component и не имеют, за исключением использования свойства привязки данных состояния анимации, доступа к полям экземпляра (если вы не создаете анимацию через AnimationBuilder конечно, что также не очень удобно или красивым либо).

Другое дело, с API веб-анимации можно проверять, отлаживать или тестировать анимации, но я не вижу, как это возможно с помощью Angular animations. Если да, не могли бы вы показать мне, как это сделать? Если это не так, я действительно не вижу преимущества использования угловых анимаций над CSS для управления.

Чистый код

Я прочитал, например, здесь пункт о том, что отделение анимации от "нормальных" стилей на самом деле разделение поведения и представления. Действительно ли объявление анимаций в стилях листы смешивания этих обязанностей? Я видел, что всегда наоборот, особенно глядя на CSS-правила в анимациях @Component я чувствовал, что у меня есть объявления CSS на одном слишком много мест.

Итак, как это происходит с Угловой анимацией?

Это просто удобная утилита для извлечения анимации от остальных стилей или же она приносит что-то достойное по размеру?
Использует ли использование угловой анимации только в особых случаях или это соглашение, которое команда выбирает, чтобы пройти весь путь?

Мне бы хотелось здесь о ощутимых преимуществах использования Angular animations. Спасибо, парни!

Ответ 1

Поэтому я сделал некоторые исследования, и хотя я не нашел аргументов или против угловых анимаций с точки зрения производительности (как уже было сказано выше), есть очень хорошие аргументы в пользу использования угловой анимации, которая должна быть достаточно хороша для пуристы, которые хотят иметь CSS только в листах, по крайней мере в некоторых случаях я проиллюстрирую ниже.

Позвольте мне перечислить некоторые полезные функции, из которых каждый из них делает убедительный случай для угловых анимаций, большинство из них можно найти в документации по угловой анимации:

Стили перехода - эти стили применяются только при переходе из одного состояния в другое - только при анимации элемента, и каждый использует их следующим образом:
```
transition('stateA => stateB', [style({...}), animate(100)])
```
Попытка сделать то же самое без Angular потребовала бы анимации CSS в стилях stateB с той же продолжительностью, что и переход или назначение временных стилей, и удаление их после продолжительности анимации через JS.
void состояние (документация). Позволяет анимировать элементы, добавляемые или удаляемые из DOM.
```
transition('stateA => void', animate(...))
```
Это очень здорово, потому что раньше, хотя было достаточно легко анимировать добавление, удаление было более сложным и требовалось для запуска анимации, дождаться его конца и только после этого удалить элемент из DOM, все с JS.
Автоматический расчет свойств '*' (документация). Позволяет выполнять традиционно сложные анимации, такие как переходы высоты для элементов с динамической высотой. Эта проблема особенно беспокоилась для пуристов CSS и требовала от JS проверять текущую высоту элемента, назначая точную высоту ему и другим процедурам, чтобы выполнить идеальную анимацию. Но теперь с помощью Angular это так просто:
```
trigger('collapsible', [
  state('expanded', style({ height: '*' })),
  state('collapsed', style({ height: '0' })),
  transition('expanded <=> collapsed', animate(100))
])
```
А анимация является гладкой, потому что фактическая высота элемента используется для перехода, а не как с преобладающим решением max-height.
Абонентские обратные вызовы (документация) - это то, что не совсем возможно с анимацией CSS (если не эмулировать с помощью setTimeout) и удобно, например. для отладки.
В отличие от изложенного в вопросе, на самом деле можно использовать поля экземпляра в качестве параметров в Angular animations, см. Этот вопрос. Я считаю, что это намного проще в использовании, чем манипулирование переменными CSS через DOM API, как показано здесь на MDN.

Понятно, что если вам нужна одна из функций, перечисленных выше, Angular - это путь. Также, когда есть много анимаций для управления в компоненте, и это только мое личное мнение, мне легче организовать анимацию по Угловому пути, чем иметь их в листах, где сложнее видеть отношения между различными состояниями элементов.