Añadir, borrar, mover y filtrar sin perder estado

Hay una prueba brutal para saber si una lista está bien construida: escribe media frase en la tercera fila, sin salir del campo de texto activa un filtro que la oculte, quítalo, y mira si tu media frase y tu cursor siguen ahí. Casi ninguna lista pasa esa prueba, porque casi todas tratan la colección como un cubo de datos que se vacía y se rellena en cada cambio, y cada rellenado fabrica elementos nuevos que no recuerdan nada. En TCA los elementos no son datos sino features con estado propio y efectos en marcha, así que la pregunta deja de ser cómo mostrar la lista correcta y pasa a ser cómo alterar la población sin matar a nadie por accidente. Esta lección es el manual de esa cirugía: cuatro operaciones, un principio único —tocar lo mínimo, direccionar por identidad— y un cambio de mentalidad sobre lo que significa filtrar.

Alta: quién fabrica la identidad

Crear un elemento es una acción del padre, porque solo el padre ve la colección, y su único trabajo delicado es de dónde sale el identificador. Fabricarlo con UUID() directamente funciona en producción y arruina cualquier test, porque el valor es distinto en cada ejecución; fabricarlo con @Dependency(\.uuid) funciona igual en producción y se vuelve una secuencia predecible bajo prueba.

@Dependency(\.uuid) var uuid

case .anadirTocado:
  state.filas.append(Fila.State(id: self.uuid(), texto: ""))
  return .none

case let .llegoDelServidor(remotas):
  for remota in remotas {
    state.filas.updateOrAppend(Fila.State(remota))  // alta o actualización
  }
  return .none

Repara en quién ejecuta el alta: el padre, siempre, porque es el único que ve la colección. Una fila no puede crear hermanas igual que no puede borrarse a sí misma, y si necesita provocar un alta —duplicarse, por ejemplo— lo pide con una acción delegada y deja que el padre decida. Esa frontera se sostiene sin esfuerzo mientras el vocabulario de la fila no mencione la palabra lista.

La distinción entre los dos gestos es la que separa una lista local de una sincronizada. append respeta la unicidad y no hace nada si el id ya existe, lo cual es correcto para un alta genuina. updateOrAppend reemplaza el valor si la identidad ya está presente y lo añade al final si no, que es exactamente la semántica que necesita un refresco desde la red: los elementos que ya conocías se actualizan sin cambiar de sitio y los nuevos se incorporan al final, sin que la colección se reconstruya y sin que nadie pierda su estado.

Baja: borrar es también cancelar

Eliminar por identidad es una línea, y su efecto secundario es la garantía que viste en la lección anterior: forEach cancela los efectos en vuelo del elemento en cuanto desaparece de la colección. Borrar no es solo quitar un valor; es terminar un proceso.

case let .borrar(offsets):
  let visibles = state.filasVisibles
  for indice in offsets {
    state.filas.remove(id: visibles[indice].id)
  }
  return .none

Ese fragmento contiene el error más caro del nivel, ya corregido. Los offsets que entrega el onDelete de SwiftUI son índices sobre lo que hay renderizado, no sobre lo que hay guardado; si la lista muestra una proyección filtrada, borrar directamente por esos índices en la colección completa elimina elementos ajenos elegidos al azar. La traducción correcta es la del código: leer la proyección visible, sacar de ella la identidad del elemento señalado, y borrar por esa identidad en la colección real. Es el mismo principio de siempre, aplicado a la frontera entre vista y estado: el índice es una coordenada local que caduca al cruzar la frontera; el id no.

Mover: el orden es un dato

IdentifiedArrayOf conserva el orden de inserción precisamente para que el orden sea observable y mutable, y ofrece el gesto que SwiftUI espera del onMove.

case let .mover(origen, destino):
  state.filas.move(fromOffsets: origen, toOffset: destino)
  return .run { [filas = state.filas] _ in
    try await self.almacen.guardarOrden(filas.map(\.id))
  }

case .ordenarCompletadasAlFinal:
  state.filas.sort { !$0.completada && $1.completada }
  return .none

Mover no crea ni destruye elementos: permuta posiciones dentro de la misma estructura, así que ningún estado se pierde y ningún efecto se cancela. La fila que estaba contando segundos sigue contando mientras el usuario la arrastra. Y como el orden vive en el estado, persistirlo es serializar una secuencia de identidades, y restaurarlo es volver a ordenarlas: la disposición de la lista deja de ser una propiedad de la interfaz para ser un hecho del dominio, testeable como cualquier otro.

Filtrar: proyectar en vez de amputar

Aquí está el cambio de mentalidad. Filtrar no debe tocar la colección. Si al activar un filtro eliminas los elementos que no encajan, los estás matando: pierden su texto a medio escribir, su foco, sus efectos en vuelo, y al quitar el filtro renacen como recién nacidos que no recuerdan nada. La colección guarda la población entera; el filtro es una lente que se pone delante.

@ObservableState
struct State: Equatable {
  var filtro: Filtro = .todas
  var filas: IdentifiedArrayOf<Fila.State> = []

  var filasVisibles: IdentifiedArrayOf<Fila.State> {
    switch filtro {
    case .todas:       return filas
    case .pendientes:  return filas.filter { !$0.completada }
    }
  }
}

Y en la vista se rebana sobre la proyección, porque el scope de una colección admite un key path de solo lectura para el estado. El estado que se muestra es la proyección; las acciones siguen viajando a la colección real por identidad.

struct ListaView: View {
  @Bindable var store: StoreOf<Lista>

  var body: some View {
    List {
      ForEach(store.scope(state: \.filasVisibles, action: \.filas)) { filaStore in
        FilaView(store: filaStore)
      }
      .onDelete { store.send(.borrar($0)) }
    }
    .toolbar {
      Picker("Filtro", selection: $store.filtro.sending(\.filtroCambio)) {
        Text("Todas").tag(Filtro.todas)
        Text("Pendientes").tag(Filtro.pendientes)
      }
    }
  }
}

Cambiar el filtro es escribir un campo del estado del padre; la proyección se recalcula, scope produce los stores de lo visible y SwiftUI anima la entrada y salida de filas. Lo que no ocurre en ningún momento es una destrucción: los elementos ocultos siguen en filas, con su texto, su foco pendiente y sus efectos vivos, esperando a que la lente vuelva a incluirlos. Ocultar y mostrar dejan de ser operaciones destructivas para convertirse en lo que siempre debieron ser: dos maneras de mirar el mismo conjunto de seres.

flowchart LR
C[Coleccion real en el estado] --> F[Proyeccion filtrada calculada]
F --> V[Vista renderiza lo visible]
V -->|indices de onDelete| T[Traducir indice visible a id]
T --> C
C -->|move y sort permutan| C
style T fill:#f9e2af,color:#11111b
style C fill:#89b4fa,color:#11111b