SwiftUI Series 09 ｜ Introducción a la animación SwiftUI: uso de animación y withAnimation

Es más probable que la animación SwiftUI dé a las personas una sensación “aparentemente simple”:

• Agregar .animation
• O empacar withAnimation

La página comienza a moverse.

Pero en proyectos reales, el problema más común con la animación es exactamente aquí:

• Se está moviendo hacia aquí también.
• Las cosas se movieron donde no deberían haberse movido.
• No hay animación para un determinado cambio de estado.
• La animación es particularmente extraña cuando se actualiza la lista.

Esto demuestra que muchas veces no lo descubrimos primero:

¿Esta animación debería adjuntarse a un determinado cambio de estado, o debería solo concluir un proceso de cambio específico?

1. El núcleo de la animación SwiftUI es “permitir que los cambios de estado se interpolen y presenten”

Esto es particularmente importante.

Si todavía usa las ideas de UIKit para comprender la animación, es fácil utilizar de forma predeterminada:

• Quiero hacer un determinado movimiento de control.

SwiftUI es más como hacer:

• Cuando el estado cambia de A a B, use animación para expresar el proceso de cambio.

Esto significa que las animaciones dependen naturalmente de los cambios de estado. Entonces lo que realmente hay que juzgar es:

• ¿Qué cambios de estado merecen ser animados?
• ¿Qué tamaño debería tener el alcance de la animación?

2. La diferencia entre .animation y withAnimation no es solo el método de escritura, sino también la granularidad del control.

Una comprensión más práctica es:

• .animation es más como adjuntar animación a ciertos tipos de cambios de estado.
• withAnimation es más como envolver explícitamente una modificación de estado específica

Entonces, cuando se usa .animation, es más como decir:

Esta vista debería tener reacciones de animación de forma predeterminada para ciertos cambios de estado.

Y withAnimation es más como decir:

Voy a hacer este cambio de estado ahora y quiero que este cambio esté animado.

Esta distinción es fundamental porque afecta directamente la controlabilidad de la animación.

3. Muchas animaciones de páginas “se moverán juntas inexplicablemente”

La razón más común es que el ámbito de acción no está cerrado.

Por ejemplo, originalmente solo quería animar un bloque expandido, pero el resultado es:

• Otros textos en la misma capa también se mueven en consecuencia
• El cambio de altura del contenedor principal hace que toda el área se anime
• Algunos diseños irrelevantes también comenzaron a realizar la transición.

Esto suele ocurrir cuando la animación se adjunta a un cambio de estado o a una jerarquía de vistas que es demasiado grande.

Entonces, cuando la animación se estropea, lo que más a menudo vuelvo a comprobar es:

• ¿De qué cambios es responsable actualmente esta capa?
• ¿La animación está ligada a una vista demasiado grande?
• ¿El cambio de estado afecta a demasiados resultados de diseño al mismo tiempo?

4. Muchas “animaciones no son bonitas” porque el modelo de estado no está claro.

Algunas animaciones parecen incómodas y son:

• El Estado en sí no está claramente diseñado.
• Un cambio cambia demasiados valores al mismo tiempo
• El nivel de diseño de la página es inestable.

Por ejemplo, un clic se activa al mismo tiempo:

• Ampliar
• Cambio de redacción publicitaria
• Cambios de altitud
• Reordenamiento de lista

Eso termina pareciendo confuso, a menudo con demasiados cambios semánticos diferentes metidos en la misma transición de estado.

5. ¿Cuándo es más adecuado utilizar withAnimation?

Prefiero usarlo en estos escenarios:

• Una acción del usuario desencadena un cambio de estado explícito
• Solo quiero que el cambio de estado sea animado esta vez.
• Quiero controlar explícitamente “si este cambio se debe mover o no”.

Por ejemplo:

• Expandir/Contraer
• Insertar/eliminar un bloque parcial
• Cambiar un determinado estado de presentación después de hacer clic

La ventaja es que la semántica es más clara: Sepa que la animación está directamente vinculada a esta acción.

6. ¿Cuándo es probable que .animation sea más peligroso?

.animation es particularmente fácil hacer que la página se “mueva ligeramente en todas partes” cuando el alcance de influencia del estado no está claramente pensado primero.

Especialmente en diseños complejos, si un cambio de estado afecta:

• Dimensiones
• Alineación
• redacción
• Jerarquía de contenedores

Colgar la animación directamente sobre ella puede hacer que toda el área cambie fácilmente.

Entonces .animation es más adecuado para aquellos:

• El alcance de la influencia es relativamente claro.
• Semántica simple de cambios de estado.
• Estabilidad del área local

escena.

7. Un juicio más práctico: ¿Esta animación expresa “una acción” o modifica “un tipo de cambio” de forma predeterminada?

Si estás expresando una acción explícita:

• Haga clic para abrir
• cerrar
• Insertar
• Eliminar

Entonces suelo considerar primero withAnimation.

Si está modificando un cambio de estado local estable, es más fácil considerar .animation.

Este juicio es muy útil porque le permite no centrarse sólo en el nombre de la API, sino volver realmente a la “semántica de la animación”.

8. Conclusión: Lo que realmente debe distinguirse en la animación SwiftUI es el límite de los cambios de estado y el límite de los efectos de animación.

Para decirlo en forma más breve, diría:

Lo más importante de la animación SwiftUI es primero distinguir: si esta animación expresa una acción específica o si agrega un efecto de transición a algún tipo de cambio de estado local.

Una vez que estos dos límites estén claros, la animación será más controlable; Si los límites no están claros, la página puede fácilmente convertirse en “moviéndose a todas partes, pero ningún lugar se mueve particularmente bien”.