Rendimiento con listas grandes: Equatable, observación y paginación

Todo lo aprendido en este nivel es correcto a cualquier escala, pero no es igual de barato a cualquier escala. Una colección de features tiene tres costes que crecen con el número de elementos y que casi nadie mide hasta que la lista va a tirones: comparar el estado, invalidar vistas y sostener efectos. Los tres se pueden controlar, y ninguno se controla optimizando el framework, porque el framework ya hace lo que puede; se controlan cambiando la forma del estado. Esta lección cierra el nivel con la pregunta que separa un prototipo de un producto: qué exactamente se vuelve lento cuando la lista pasa de cien a cincuenta mil filas, y qué decisiones de modelado hacen que el número deje de importar.

El coste de Equatable

La igualdad sintetizada de una estructura compara cada campo en orden y corta en la primera diferencia. Eso convierte la comparación de dos colecciones iguales en el peor caso posible: hay que recorrer los n elementos y, dentro de cada uno, todos sus campos. Con estados de fila pequeños es ruido; con estados gordos es un desastre silencioso que aparece en el perfilador como un == sintetizado ocupando la mitad del cuadro.

// Caro de comparar y caro de copiar
struct State: Equatable, Identifiable {
  let id: UUID
  var miniatura: Data          // cientos de KB por fila
  var textoCompleto: String    // el documento entero
}

// Barato: el estado guarda referencias, no cargas
struct State: Equatable, Identifiable {
  let id: UUID
  var miniaturaURL: URL
  var resumen: String
}

La regla es que el estado de un elemento debe pesar lo que pesa una fila en pantalla, no lo que pesa el objeto de dominio completo. Los datos binarios, los documentos y los resultados decodificados grandes viven en una caché detrás de una dependencia y el estado guarda su identificador. La tentación contraria —escribir un == a mano que solo compare los ids para que la comparación sea barata— es peor que el problema: una igualdad que miente hace que SwiftUI y TestStore no vean cambios que sí ocurrieron, y los fallos resultantes son de los que cuestan una tarde por cada uno.

Conviene saber además dónde se paga. En el TCA anterior a la observación, WithViewStore deduplicaba comparando el estado de vista completo en cada acción, así que una colección grande pagaba su comparación lineal en cada tecla pulsada. Con @ObservableState esa comparación desaparece del camino caliente, porque la invalidación pasa a ser por propiedad accedida; pero Equatable sigue siendo necesario y sigue usándose en las aserciones de TestStore, en las animaciones y en los observadores de cambio. Barato de comparar no es opcional, solo dejó de ser urgente en todos los frames.

Observación por elemento, y cómo estropearla

Con la vista de fila observando su propio store rebanado, teclear en la fila cuarenta invalida la fila cuarenta y nada más. Es una propiedad que se obtiene gratis y se pierde con una sola línea distraída en el padre.

// Estropea la observación: el padre lee la colección entera
var body: some View {
  VStack {
    Text("\(store.filas.count) elementos")            // toca toda la colección
    Text("\(store.filas.filter(\.completada).count)")  // y encima la recorre
    List {
      ForEach(store.scope(state: \.filas, action: \.filas)) { s in
        FilaView(store: s)
      }
    }
  }
}

Al leer store.filas en su cuerpo, el padre se suscribe a la colección completa: cualquier cambio en cualquier elemento reevalúa ese cuerpo, y con él la construcción del ForEach. La observación por fila sigue funcionando, pero has añadido encima un trabajo lineal por cada pulsación. El arreglo es de modelado, no de sintaxis: mantener los agregados como campos almacenados que el reducer actualiza cuando corresponde, o aislar la cabecera en una subvista que observe solo ese campo. Lo mismo vale para las proyecciones calculadas de la lección anterior: filasVisibles es lineal cada vez que se lee, y si el cuerpo la lee varias veces por frame con decenas de miles de elementos, ahí está tu cuello de botella.

Hay un segundo modo de estropearlo, esta vez desde el reducer. IdentifiedArrayOf es un tipo valor con copia sobre escritura, de modo que mutar un elemento por su id modifica el almacenamiento en el sitio cuando la referencia es única, y no toca a nadie más. Reconstruir la colección, en cambio, sustituye el almacenamiento entero y marca como cambiado todo lo que hubiera dentro.

// Rehace la estructura completa: lineal, y todos los elementos cuentan como cambiados
state.filas = IdentifiedArrayOf(uniqueElements: state.filas.map { fila in
  var copia = fila
  copia.visto = true
  return copia
})

// Mutación dirigida: toca exactamente a quien hay que tocar
for id in state.pendientesDeMarcar {
  state.filas[id: id]?.visto = true
}

Las dos versiones producen el mismo estado final y cuestan cosas muy distintas, y la diferencia se amplifica cuando la operación es frecuente. La heurística es la de siempre en este nivel, ahora en clave de rendimiento: si sabes a quién quieres tocar, nómbralo; recorrer la colección entera solo está justificado cuando de verdad cambian todos.

Paginación: crecer sin reconstruir

La respuesta estructural a una colección enorme no es optimizar su manejo sino no tenerla entera. La paginación encaja con naturalidad porque la unicidad por identidad hace que las páginas solapadas —el caso normal cuando el servidor inserta mientras tú lees— no produzcan duplicados.

enum CancelID { case pagina }

case let .filaAparecio(id):
  guard id == state.filas.last?.id, !state.cargando else { return .none }
  state.cargando = true
  return .run { [cursor = state.cursor] send in
    await send(.paginaLlego(try await self.api.pagina(cursor)))
  }
  .cancellable(id: CancelID.pagina, cancelInFlight: true)

case let .paginaLlego(pagina):
  state.cargando = false
  state.cursor = pagina.siguienteCursor
  for elemento in pagina.elementos {
    state.filas.updateOrAppend(Fila.State(elemento))  // sin duplicados, por id
  }
  return .none

Tres detalles cargan todo el peso. El disparo por identidad —comparar el id de la fila que apareció con el de la última— evita la aritmética de índices que se rompe en cuanto hay filtro. El cancelInFlight garantiza que un usuario que hace scroll rápido no encadena cinco peticiones simultáneas: la nueva sustituye a la anterior. Y updateOrAppend convierte el solapamiento de páginas en actualización silenciosa en vez de en filas repetidas, sin que tengas que escribir una sola comprobación.

flowchart TD
N[La lista crece] --> EQ[Coste de comparar es lineal]
N --> OB[Coste de observar depende del padre]
N --> EF[Coste de efectos depende de cuantos existen]
EQ --> A[Estado del elemento ligero]
OB --> B[Leer campos y no la coleccion]
EF --> C[Subir el efecto comun al padre]
A --> R[Escala estable]
B --> R
C --> R
R --> P[Paginar con updateOrAppend y cancelInFlight]
style R fill:#a6e3a1,color:#11111b