SwiftUI Series 02 ｜ Introducción al sistema de diseño SwiftUI: VStack, HStack, ZStack, Spacer y frame

Cuando aprendí este contenido por primera vez, fue más fácil caer en un estado al diseñar el diseño de SwiftUI:

• VStack Puedo
• HStack Yo también lo haré
• Spacer parece entender
• frame también escribe con frecuencia.

Pero a medida que la página se vuelve más compleja, comienzan a aparecer estos problemas familiares:

• Esta vista no está completa.
• Se agregó frame pero aún no está alineado.
• Spacer Tan pronto como se coloque, desplazará otras cosas.
• Después de varios niveles de anidamiento, la página “no puede decir qué está mal, pero no se ve bien”.

Esto muestra que muchas veces no entendemos realmente qué hace el diseño de SwiftUI.

1. Lo más importante del diseño de SwiftUI es el proceso de negociación del tamaño.

Si solo entiende el diseño como “qué pila usar para colocar elementos”, pronto se quedará atascado. Porque el verdadero núcleo del diseño de SwiftUI es el proceso de negociación de tamaño, que puede entenderse aproximadamente como:

1. La supervisión da un espacio disponible o tamaño propuesto.
2. La subvista decide qué tamaño quiere tener en función de esta propuesta.
3. Luego, el contenedor principal organiza el diseño de acuerdo con el tamaño devuelto por la subvista.

En otras palabras, el diseño es una negociación constante entre padre e hijo.

Una vez que se comprende esta premisa, muchas preguntas aparentemente metafísicas quedan claras:

• Algunos frame simplemente están cubiertos con una carcasa.
• Text y Spacer se comportan de manera muy diferente cuando se combinan
• Algunos problemas de alineación se compensan esencialmente durante la etapa de propuesta de tamaño.

2. VStack, HStack, ZStack La verdadera diferencia es “quién lidera qué lógica de ubicación”

En la superficie:

• VStack Dispuesto verticalmente
• HStack dispuestos horizontalmente
• ZStack filas apiladas

Esto es ciertamente cierto, pero si solo recuerda esto, aún se sentirá confundido cuando se encuentre con diseños complejos.

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

• VStack organiza principalmente subelementos verticalmente
• HStack organiza principalmente subelementos horizontalmente
• ZStack apila principalmente varios elementos en la misma área

El punto clave es pensar con claridad:

• ¿Cuál es el eje central de la página actual?
• ¿Qué capa es responsable del diseño principal? -¿Qué capa es sólo alineación y decoración local?

Muchos diseños están escritos de manera desordenada y los niveles primario y secundario no se distinguen claramente.

3. El valor de Spacer está “comiéndose el espacio restante”

Cuando utilice Spacer por primera vez, intuitivamente lo entenderá como “agregar un cuadro vacío”.

Esto puede dar lugar a muchos abusos.

Más precisamente, lo que hace Spacer es:

Consuma todo el espacio restante posible en la dirección del eje principal del contenedor actual.

Por ejemplo, en HStack, se come el espacio horizontal; en VStack, se come el espacio vertical.

Una vez entendido así, resulta más fácil juzgar:

-¿Es necesario tener un espaciamiento fijo o destinar espacio sobrante?

• ¿Debería utilizarse aquí padding o Spacer?
• Spacer Si se coloca en la posición incorrecta, se desplazará el centro de gravedad de todo el diseño.

Muchas páginas “se ven un poco peor” porque se usa Spacer donde se deben usar restricciones fijas. Como resultado, la lógica de asignación de espacio restante cambia silenciosamente el diseño.

4. frame se malinterpreta más fácilmente: no se trata necesariamente de “modificar el tamaño del contenido”, en muchos casos simplemente envuelve una capa de cuadros de diseño

Este es uno de los puntos más fáciles para que los principiantes de SwiftUI se queden atascados.

Una situación común es escribir:

Text("Hello")
  .frame(maxWidth: .infinity)

Pensé que estaba estirando Text. Para ser más precisos, en muchos casos, se proporciona un área de diseño más grande fuera del Text, en lugar de cambiar el tamaño del contenido interno del propio Text.

Esto explica muchas confusiones comunes:

• Parece más ancho, pero el texto aún no está alineado donde quiero que esté.
• Solo úsalo con alignment
• El mismo frame tiene diferentes efectos en diferentes vistas.

Por lo tanto, la clave para frame no es “cambiar el tamaño”, sino “qué límites de diseño se agregan a la vista”.

5. La verdadera causa fundamental de muchos problemas de diseño es que la “capa de diseño principal” y la “capa de modificación local” están mezcladas.

Tomemos un antipatrón muy común:

• Una capa exterior VStack
• Hay varias capas dentro de HStack
• Agregue frame a cada capa
• Mezcle un poco más Spacer
• Finalmente, confía en padding para repararlo hasta que puedas verlo.

Este tipo de método de escritura ciertamente puede producir resultados a corto plazo, pero una vez que cambias la longitud de la copia, el ancho de la pantalla o la fuente dinámica, el diseño comenzará a variar.

La raíz del problema suele ser:

• ¿Qué capa es responsable de la estructura principal?
• ¿Qué capa es responsable de la alineación local? -¿Qué capa es sólo una modificación visual?

No hay capas.

Una vez que el diseño pierde su sentido de jerarquía, “dependerá de un montón de modificadores para eliminar temporalmente la posición” en lugar de depender de la estructura que se establecerá de forma natural.

6. Una forma más práctica de pensar en el diseño: primero determine el eje principal, luego determine el espacio restante y luego determine la alineación local.

Si hoy quiero crear una página un poco más compleja, suelo pensar en este orden:

1. ¿Esta zona está dominada horizontal o verticalmente?
2. ¿A quién debería dejarle el espacio restante?
3. Qué lugares requieren un espacio fijo y qué lugares requieren un espacio flexible.
4. Qué áreas sólo están alineadas localmente y no deberían afectar a su vez la estructura global.

Esta orden puede reducir significativamente la situación de “más reparaciones y más caos”. Porque te obliga a decidir primero la estructura y luego decidir la modificación, en lugar de simplemente depender del modificador para acumular los resultados.

7. Muchas páginas de SwiftUI “siempre se ven un poco peor”

En realidad, muchos problemas de página se deben a una expresión de estructura insuficientemente clara.

Las manifestaciones comunes incluyen:

• La relación entre bloques de información no es lo suficientemente estable.
• Mientras el texto sea largo, desplazará otras cosas.
• La misma tarjeta tiene proporciones extrañas en diferentes pantallas.

Estas preguntas suelen ser:

• La lógica de asignación de espacio no está clara.
• Se mezclan el eje principal de diseño y las modificaciones locales.
• El lugar fijo no es fijo
• La flexibilidad se ha vuelto a anotar.

Por lo tanto, aprender verdaderamente la distribución es aprender a juzgar cómo se debe asignar el espacio.

8. Conclusión: Lo que realmente necesita aprender al comenzar con el diseño de SwiftUI es la negociación de espacios en lugar de los nombres de control.

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

Lo que realmente necesita dominar sobre el diseño de SwiftUI es cómo la vista principal propone el tamaño, cómo responde la subvista al tamaño y cómo se coloca el contenedor en función de estos resultados.

Una vez que se establezca esta relación básica, muchas cuestiones de diseño cambiarán de “metafísicas” a “razonables”.