UICollectionView moderno: composición e identidad

Hay un experimento mental que ordena esta lección entera: si Apple hubiera diseñado UICollectionView en 2019 en lugar de en 2012, se parecería mucho más a SwiftUI de lo que se parece a UIKit. Y en cierto sentido eso fue justamente lo que ocurrió, porque la reforma presentada aquel año no añadió funciones a la API vieja sino que sustituyó sus dos partes más dolorosas por dos ideas declarativas puras. El layout dejó de ser una clase que se subclasea calculando atributos a mano y pasó a ser una descripción compuesta de elementos, grupos y secciones. Los datos dejaron de manipularse por índices con inserciones y borrados coordinados a mano y pasaron a expresarse como una instantánea de identificadores que el sistema compara con la anterior para deducir la animación. El resultado es una API que sigue siendo referencia siete años después, que resuelve problemas que SwiftUI todavía no cubre con la misma solvencia, y cuyas dos ideas centrales son exactamente las que uno reconoce, ya interiorizadas, en el modelo declarativo.

De subclasear un layout a describirlo

Conviene recordar el punto de partida, porque sin él la reforma parece un capricho de estilo. Antes de 2019, cualquier disposición que no fuera una rejilla uniforme exigía escribir una subclase de layout y responder a mano a cuatro preguntas: cuál es el tamaño total del contenido, qué atributos tiene el elemento en cada índice, qué elementos caen dentro de un rectángulo visible y qué debe invalidarse cuando cambia algo. Ese código era largo, difícil de probar, imposible de componer y una fuente inagotable de errores de rendimiento, porque la tercera pregunta se contesta miles de veces por segundo durante el desplazamiento.

El diseño composicional elimina la subclase por completo y la sustituye por una expresión que se construye de dentro hacia fuera. Un elemento describe un hueco; un grupo describe cómo se disponen varios huecos en una línea horizontal o vertical; una sección envuelve un grupo y le añade márgenes, elementos suplementarios y comportamiento de desplazamiento; y el layout final es una función que, dado el índice de sección y el entorno, devuelve la sección correspondiente.

flowchart TB
a[NSCollectionLayoutSize con dimensiones fraccionales absolutas o estimadas] --> b[NSCollectionLayoutItem]
b --> c[NSCollectionLayoutGroup horizontal o vertical]
c --> d[NSCollectionLayoutSection con margenes y suplementarios]
d --> e[UICollectionViewCompositionalLayout como funcion de seccion y entorno]

La pieza que hace componible todo el sistema es el tipo de dimensión, que admite cuatro formas: fracción de la anchura del contenedor, fracción de la altura, valor absoluto en puntos y valor estimado que el sistema ajustará midiendo el contenido real. La cuarta es la que trajo el dimensionado automático a las colecciones sin una línea de cálculo, y su coste conviene conocerlo: una estimación muy alejada del valor real obliga a recalcular durante el desplazamiento y produce saltos en la barra de scroll.

// Un carrusel horizontal dentro de una lista vertical, sin subclases
func seccionCarrusel() -> NSCollectionLayoutSection {
    let elemento = NSCollectionLayoutItem(layoutSize: .init(
        widthDimension: .fractionalWidth(1),
        heightDimension: .fractionalHeight(1)))

    let grupo = NSCollectionLayoutGroup.horizontal(layoutSize: .init(
        widthDimension: .fractionalWidth(0.85),
        heightDimension: .absolute(220)), subitems: [elemento])

    let seccion = NSCollectionLayoutSection(group: grupo)
    seccion.orthogonalScrollingBehavior = .groupPagingCentered
    seccion.interGroupSpacing = 12
    return seccion
}

El desplazamiento ortogonal que aparece en ese fragmento merece una mención aparte, porque es la funcionalidad que más trabajo ahorraba antes de existir. Permite que una sección se desplace horizontalmente dentro de una colección vertical con paginación, centrado o desplazamiento continuo, reutilizando celdas correctamente y sin anidar una colección dentro de otra, que era la solución clásica y una fuente crónica de problemas de reutilización y de gestos en conflicto.

Identidad en lugar de índices

La segunda mitad de la reforma es más profunda que la primera porque cambia el modelo de datos, no solo la sintaxis. La fuente de datos clásica respondía preguntas por índice y exigía que cada mutación se comunicase con una operación por lotes en la que el número de elementos antes y después tenía que cuadrar exactamente con las inserciones y borrados declarados. Cuando no cuadraba, la aplicación no fallaba silenciosamente: se caía con una excepción, y ese fallo era uno de los más comunes de la plataforma.

La fuente diferenciable elimina esa categoría entera de errores por construcción. En lugar de decir qué operaciones se realizaron, se declara cuál es el estado actual mediante una instantánea que contiene identificadores de sección y de elemento, y el sistema calcula por diferencia qué animaciones corresponden. El paralelo con el modelo declarativo es exacto: se describe el resultado y el motor deduce la transición.

enum Seccion: Hashable { case destacados, recientes }

var instantanea = NSDiffableDataSourceSnapshot<Seccion, Articulo.ID>()
instantanea.appendSections([.destacados, .recientes])
instantanea.appendItems(destacados.map(\.id), toSection: .destacados)
instantanea.appendItems(recientes.map(\.id), toSection: .recientes)
await fuente.apply(instantanea, animatingDifferences: true)

Hay un detalle de diseño en ese código que decide si la API funciona o si produce bugs sutiles, y conviene subrayarlo: la instantánea contiene identificadores, no modelos. La tentación de meter el modelo completo es fuerte y el compilador la permite si es conformante a la comparación por igualdad y al cálculo de resumen, pero la consecuencia es que cualquier cambio en un campo produce un identificador distinto, el sistema lo interpreta como un borrado seguido de una inserción, y la fila desaparece y reaparece con animación en lugar de actualizarse en su sitio.

Desde iOS 15 existe una distinción que mucha gente ignora y que tiene efecto directo en la fluidez. Recargar un elemento destruye la celda y crea otra; reconfigurarlo conserva la celda existente y vuelve a aplicarle su configuración de contenido. Para el caso habitual —un contador que cambia, un estado que pasa de pendiente a hecho— reconfigurar es correcto, es notablemente más barato y evita el parpadeo. Recargar solo tiene sentido cuando la celda debe cambiar de tipo o de estructura.

El complemento de 2020

Un año después de la reforma llegó la pieza que cerró el círculo y que explica por qué UITableView dejó de tener razón de ser. La configuración de lista permite que una sección composicional adopte la apariencia y el comportamiento de una tabla nativa —separadores, estilos agrupados e insertados, acciones de deslizamiento, celdas expandibles en esquema— sin abandonar la colección. A partir de ahí, cualquier layout es expresable con una sola clase de vista.

Merece atención que esas tres piezas empujan en la misma dirección: reducir la superficie mutable de la celda hasta convertirla en una función de su configuración. Una celda moderna bien escrita no tiene métodos de actualización ni estado interno; recibe una configuración y la aplica. Quien haya escrito vistas de SwiftUI reconoce el patrón de inmediato, y esa convergencia no es casual sino el resultado de que ambos equipos llegaron a la misma conclusión sobre cómo debe comportarse una celda reutilizable.

Por qué sigue siendo la referencia

Queda la pregunta que importa a alguien que trabaja en declarativo: si SwiftUI tiene List, LazyVGrid y contenedores de desplazamiento con toda la maquinaria moderna, para qué sirve conocer esto. Hay tres respuestas y ninguna es nostálgica.

La primera es de cobertura. Layouts genuinamente irregulares —secciones con reglas distintas, elementos que ocupan varias columnas, mosaicos con proporciones variables, desplazamiento ortogonal con paginación centrada— siguen siendo mucho más directos de expresar con la jerarquía composicional que con rejillas perezosas, donde a menudo hay que simular la irregularidad con contenedores anidados y cálculos manuales.

La segunda es de escala. En colecciones muy grandes con actualizaciones frecuentes, la combinación de reutilización explícita, prefetch y reconfiguración selectiva ofrece un control fino sobre el trabajo por cuadro que el modelo declarativo administra por ti y, cuando decide mal, no expone palanca para corregirlo. No es un argumento contra SwiftUI, es un argumento sobre dónde está el techo.

La tercera es conceptual y es la que más rendimiento intelectual da. Las dos ideas de la reforma —describir el layout en lugar de calcularlo, y describir el estado por identidad en lugar de por operaciones— son precisamente las ideas sobre las que se construyó SwiftUI. Estudiarlas en un entorno donde son opcionales y donde se ve el mecanismo enseña más que usarlas en un entorno donde son obligatorias e invisibles.