Prioridades y flexibilidad: cómo se reparte el espacio entre hermanos

Dos textos en la misma fila, uno largo y otro corto, y el largo aparece truncado con puntos suspensivos mientras al corto le sobra sitio. Es la escena que todo el mundo encuentra en su primera semana y la que suele resolverse por prueba y error, poniendo anchos fijos hasta que la cosa cuadra. Lo que ocurre debajo no tiene nada de arbitrario: un stack ejecuta un algoritmo de reparto perfectamente determinista, que empieza midiendo cuánto puede estirarse o encogerse cada hijo, sigue ordenándolos por esa capacidad de adaptación y termina sirviéndolos por turnos, restando de la bolsa común lo que cada uno se lleva. Quien conoce ese algoritmo no necesita anchos fijos: necesita cambiar el turno, y para eso hay exactamente dos herramientas.

El reparto: de menos flexible a más flexible

Antes de proponer nada en serio, un HStack interroga a cada hijo dos veces. Le propone .zero para averiguar su tamaño mínimo, y le propone .infinity para averiguar el máximo. La diferencia entre ambos números es la flexibilidad de ese hijo en ese eje: cuánto margen tiene para adaptarse. Un Spacer va de cero a infinito y es máximamente flexible; una Image sin resizable devuelve lo mismo en ambos sondeos y su flexibilidad es cero; un Text va del ancho de su palabra más larga al ancho de todo su contenido en una línea.

Con esos rangos en la mano, el stack ejecuta un reparto codicioso:

1. Resta del ancho disponible el espaciado que le corresponde entre elementos.
2. Ordena a los hijos de menos flexible a más flexible.
3. Al primero de la cola le propone la bolsa restante dividida entre el número de hijos que aún no han sido servidos.
4. El hijo responde con su tamaño real, que puede ser menor que lo ofrecido. Lo que devuelve se resta de la bolsa y el hijo sale de la cola.
5. Repite con el siguiente, recalculando siempre la división con la bolsa y el recuento actualizados.

flowchart TB
bolsa[Ancho disponible menos el espaciado] --> sondeo[Sondear cada hijo con cero y con infinito]
sondeo --> orden[Ordenar de menos flexible a mas flexible]
orden --> turno[Proponer bolsa dividida entre los pendientes]
turno --> resp[El hijo devuelve su tamano real]
resp --> resta[Restar de la bolsa y quitar de la cola]
resta --> turno
resta --> fin[Cuando la cola queda vacia se colocan todos]
style bolsa fill:#f5c2e7,color:#11111b
style orden fill:#89b4fa,color:#11111b
style fin fill:#a6e3a1,color:#11111b

Ese sondeo no es una abstracción inaccesible: es exactamente lo que puedes hacer tú desde el protocolo de la lección cinco, y verlo escrito ayuda a fijar la idea.

// Lo que hace un contenedor antes de repartir nada
let minimo = subview.sizeThatFits(.zero).width
let maximo = subview.sizeThatFits(.infinity).width
let flexibilidad = maximo - minimo

El orden es lo que hay que grabar, porque no es caprichoso. Servir primero a quien menos puede adaptarse es la única política que no desperdicia espacio: una vista rígida va a coger lo que necesita sea cual sea la propuesta, así que preguntarle pronto permite que las flexibles absorban después lo que quede. El orden inverso repartiría a partes iguales entre todos y luego descubriría que a las rígidas les sobra o les falta, obligando a una segunda pasada. Recuerda que en este sistema no hay segundas pasadas.

Ahora el caso de los dos textos se explica solo. Ambos tienen flexibilidad parecida, ninguno es claramente más rígido, así que el stack los sirve en orden de aparición dividiendo la bolsa en dos mitades. El texto corto pide menos de su mitad y devuelve lo suyo; el largo recibe la mitad más lo que sobró y aun así no le llega, y hace lo único que un Text sabe hacer en esa situación: truncar.

Las prioridades cambian el turno

layoutPriority acepta un Double que vale cero por omisión en todas las vistas. Su efecto es tajante: el stack agrupa a los hijos por prioridad y sirve los grupos de mayor a menor, ofreciendo al grupo de más prioridad toda la bolsa antes de que los demás vean nada. Solo dentro de cada grupo se aplica el reparto por flexibilidad de la sección anterior.

HStack {
    Text("Un titular largo que no deberia truncarse jamas")
        .layoutPriority(1)
    Text("secundario")
}

Aquí el titular se sirve solo, con la bolsa entera a su disposición, y devuelve lo que necesite. Lo que quede pasa al segundo texto, que se apañará o truncará. Fíjate en lo que no ha ocurrido: nadie ha fijado un ancho, nadie ha calculado proporciones, y el resultado sigue adaptándose al Dynamic Type, a la rotación y a la traducción al alemán. Cambiar el turno es una intervención mucho más barata y mucho más robusta que imponer números.

Los valores negativos son legales y a veces son la expresión más honesta de la intención. Marcar una vista como sacrificable dice algo distinto que marcar a otra como preferente, aunque el orden resultante sea el mismo, y quien lea el código dentro de seis meses agradecerá la diferencia:

HStack {
    Text(titulo)
    Text(subtitulo).layoutPriority(-1)   // este es el que puede ceder
    Image(systemName: "chevron.right")
}

fixedSize: renunciar a negociar

fixedSize hace una sola cosa, y de ella se derivan todos sus usos y todas sus trampas: propone a su hijo nil en el eje indicado, es decir, le pide su tamaño ideal, y después informa hacia arriba de ese tamaño ideal ignorando por completo lo que el padre hubiera propuesto. El resultado es una vista de flexibilidad cero: sondeada con .zero y con .infinity devuelve el mismo número las dos veces.

HStack {
    Text("Un titular largo que no deberia truncarse jamas")
        .fixedSize(horizontal: true, vertical: false)
    Text("secundario")
}

Fíjate en que los dos ejes se controlan por separado, y eso importa más de lo que parece. El uso más frecuente del modificador en apps reales es exactamente el contrario del ejemplo: fijar el eje vertical de un texto dentro de una columna estrecha, para que pueda ocupar todas las líneas que necesite en lugar de comprimirse a una sola.

VStack {
    Text(descripcionLarga)
        .fixedSize(horizontal: false, vertical: true)
    boton
}

Aquí el ancho se sigue negociando con normalidad, y solo la altura se pide como ideal. La variante sin argumentos, fixedSize(), fija los dos ejes a la vez y es la que más desbordamientos provoca, porque renuncia a negociar en un eje donde casi nunca hacía falta.

Este código también evita el truncamiento, pero por un camino distinto al de la prioridad, y la diferencia importa. Con layoutPriority el titular sigue negociando: si de verdad no cabe, se partirá o truncará antes que desbordar. Con fixedSize el titular ha dejado de negociar: si no cabe, se desborda fuera del stack y se dibuja encima de sus hermanos. Uno pide preferencia, el otro renuncia al proceso.

Diagnosticar un reparto

Antes de tocar nada conviene saber qué tres preguntas se están respondiendo, y en qué orden: cuánto puede encoger cada hijo, en qué turno se le sirve, y cuánto quedaba en la bolsa cuando le llegó. Un reparto insatisfactorio siempre se explica por una de las tres, y cada una tiene su propia herramienta.

La herramienta de diagnóstico es el sondeo hecho a mano. Envuelve el hijo sospechoso en un contenedor que le proponga .zero y otro que le proponga .infinity, mira los dos números, y compáralos con el ancho que realmente recibió. Si el mínimo ya es mayor que su parte de la bolsa, ninguna prioridad lo va a salvar y el problema está en el contenido. Si el mínimo cabe pero el resultado está truncado, el problema es de turno y layoutPriority lo resuelve. Si el resultado ignora la propuesta y desborda, hay un fixedSize o un frame rígido escondido en la cadena.