¿Cuál es el propósito de las animaciones angulares?


Me he estado preguntando desde hace algún tiempo por qué debería usar animaciones angulares sobre animaciones CSS. Veo pocas áreas que uno podría considerar antes de usarlas:


Rendimiento

En el primer paso encontré esta pregunta que trata solo del lado performace de las cosas. La respuesta aceptada no me satisface porque establece que uno debe usar animaciones CSS siempre que sea posible para que las optimizaciones como ejecutar las animaciones por separado el hilo se puede aplicar . Esto no parece ser cierto, porque La documentación Angular establece

Las animaciones angulares son construidas sobre la API estándar de Animaciones web y se ejecutan de forma nativa en navegadores que las soportan.

(énfasis mío)

Y cuando miramos Web Animations API Draft vemos que las mismas optimizaciones se pueden aplicar a las Animaciones Web como a CSS especificado en las hojas.

, Mientras que es posible utilizar ECMAScript para realizar animaciones usando requestAnimationFrame [HTML], tales animaciones se comportan de manera diferente a la animación declarativa en términos de cómo se representan en la cascada CSS y las optimizaciones de rendimiento que son posibles, como realizar la animación en un subproceso separado. Usando la interfaz de programación Web Animations, es posible crear animaciones a partir de script que tengan las mismas características de comportamiento y rendimiento que las declarativas animaciones.

(énfasis mío de nuevo)

Aparte de que algunos navegadores como IE no admiten Animaciones web, ¿hay alguna razón para usar declaraciones CSS sobre animaciones angulares o viceversa? Los veo como performace intercambiable-sabio.


Más control sobre las animaciones

Esto podría parecer un argumento para animaciones angulares, porque puede pausar la animación o usar variables JS con ella, etc., pero lo mismo es cierto mientras usando eg. CSS animation-play-state: pause o usando variables CSS especificadas en JS, véase documentación.

Ahora puedo ver que podría ser un inconveniente establecer las variables CSS en código JS, pero lo mismo es cierto mientras se usan animaciones angulares. Estos se declaran típicamente en @Component animations campo y no tienen, excepto a través de la propiedad animation state data bound, acceso a los campos de instancia (si no crea su animación a través de AnimationBuilder, por supuesto, lo cual, por cierto, tampoco es muy conveniente o hermoso bien).

Otro punto es, con Web Animations API es posible inspeccionar, depurar o probar las animaciones, pero no veo cómo esto es posible con animaciones Angulares. Si lo es, ¿podría mostrarme cómo? Si no lo es, realmente no veo ninguna ventaja de usar animaciones angulares sobre las CSS por el bien del control tampoco.


Código limpiador

He leído por ejemplo aquí un párrafo que indica que separar las animaciones de los estilos "normales" son en realidad separación de comportamiento y presentación. ¿Es realmente declarar animaciones en hojas de estilos mezclando esas responsabilidades? Vi que siempre al revés, especialmente mirando las reglas CSS en las animaciones @Component me dio la sensación de tener declaraciones CSS en demasiados lugares.


Entonces, ¿cómo es con las animaciones angulares?

  • Es solo una utilidad de conveniencia para extraer animaciones del resto de los estilos, o trae ¿algo digno en cuanto a características?
  • ¿El uso de animaciones angulares solo vale la pena en casos especiales o es una convención que un equipo elige hacer todo el camino con ella?

Me encantaría hablar aquí sobre las ventajas tangibles de usar animaciones angulares. Gracias chicos por adelantado!

Author: Dan Macák, 2018-04-03

1 answers

Así que investigué un poco y aunque no encontré ningún argumento a favor ni en contra de las animaciones Angulares en cuanto al rendimiento (como ya se dijo en la pregunta anterior), hay muy buenos argumentos para usar las animaciones Angulares en cuanto a características que deberían ser lo suficientemente buenos para los puristas que quieren tener CSS solo en hojas, al menos en ciertos casos lo ilustraré a continuación.

Permítanme enumerar algunas características útiles de las que cada uno por sí solo hace un caso convincente para las animaciones angulares, la mayoría de se pueden encontrar en Documentación de animaciones angulares :

  1. Estilos de transición - estos estilos solo se aplican durante la transición de un estado a otro - solo mientras un elemento está siendo animado, y uno los usa así:

    transition('stateA => stateB', [style({...}), animate(100)])
    

    Intentar hacer lo mismo sin Angular requeriría una animación CSS en estilos 'stateB' con la misma duración que la transición o asignar estilos temporales por el momento y eliminarlos después de la duración de la animación vía JS.

  2. El void estado (documentación) - Permite animar los elementos que se agregan o eliminan del DOM.

    transition('stateA => void', animate(...))
    

    Esto es muy genial porque anteriormente, aunque era bastante fácil animar la adición, la eliminación era más complicada y requería activar la animación, esperar hasta su final y solo después eliminar el elemento del DOM, todo con JS.

  3. Propiedad automática cálculo '*' (documentación ) - Permite realizar animaciones tradicionalmente difíciles como transiciones de altura para elementos con altura dinámica. Este problema era especialmente molesto para los puristas de CSS y requería que JS verificara la altura actual de un elemento, asignándole la altura precisa y otros procedimientos para realizar una animación perfecta. Pero ahora con Angular es tan fácil como esto:

    trigger('collapsible', [
      state('expanded', style({ height: '*' })),
      state('collapsed', style({ height: '0' })),
      transition('expanded <=> collapsed', animate(100))
    ])
    

    Y la animación es suave porque el actual altura del elemento se utiliza para la transición, no como con el prevalente max-height solución .

  4. Devolución de llamada de animación (documentación ) - esto es algo que no era exactamente posible con animaciones CSS (si no tal vez emulado con setTimeout) y es útil por ejemplo. para depurar.

  5. A diferencia de lo indicado en la pregunta, en realidad es posible usar campos de instancia como parámetros en animaciones angulares , véase esta pregunta. Me resulta mucho más fácil de usar que manipular variables CSS a través de la API DOM como se muestra aquí en MDN.

Está claro, que si necesita una de las características enumeradas anteriormente, Angular es el camino a seguir. También cuando hay muchas animaciones para administrar en un componente, y esto es solo mi opinión personal, me resulta más fácil organizar animaciones de forma Angular que tenerlas en hojas, donde también es más difícil ver las relaciones entre varios elementos estado.

 12
Author: Dan Macák,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-04-11 19:13:21