En la vista: un store propio para cada fila

Hay una tentación casi irresistible al llegar a la vista: como el padre tiene la colección entera, iterar sobre los valores y pasar a cada celda su modelo y una closure para avisar de los toques. Funciona, y es exactamente lo que rompe todo lo construido en las dos lecciones anteriores, porque devuelve la fila al mundo de los callbacks anónimos donde nadie sabe quién habló. La alternativa de TCA es tratar la vista como trata al reducer: si el reducer hijo se obtiene multiplicando uno por la colección, la vista hija se obtiene rebanando el store del padre en un store por elemento. Cada fila recibe entonces un StoreOf propio, cerrado sobre su identidad, y vuelve a ser lo que era en el reducer: una feature completa que ignora por completo que tiene noventa y nueve hermanas.

Rebanar el store de la colección

scope es la misma operación que ya conoces para un hijo único, con una diferencia de tipo: cuando el key path de estado apunta a una colección identificada y el de acción a una acción dirigida, el resultado no es un store sino una colección de stores, uno por elemento, cada uno identificado por el id de su elemento.

struct ListaView: View {
  let store: StoreOf<Lista>

  var body: some View {
    List {
      ForEach(store.scope(state: \.filas, action: \.filas)) { filaStore in
        FilaView(store: filaStore)
      }
    }
  }
}

struct FilaView: View {
  let store: StoreOf<Fila>

  var body: some View {
    HStack {
      Text(store.texto)
      Spacer()
      Text("\(store.segundos)s").monospacedDigit()
    }
    .onAppear { store.send(.alAparecer) }
  }
}

FilaView no recibe un índice, ni un modelo suelto, ni una closure de callback: recibe un store y con eso le basta para leer su estado y enviar sus acciones. Ese store está preconfigurado para envolver cada acción con la identidad correcta, así que store.send(.alAparecer) desde la tercera fila llega al reducer padre como .filas(.element(id: idDeLaTercera, action: .alAparecer)) sin que la vista escriba una palabra sobre identidades. La simetría con el reducer es exacta: allí el aislamiento lo garantizaba forEach, aquí lo garantiza scope.

ForEachStore y su sucesor observado

Antes de la llegada de @ObservableState, recorrer una colección de features exigía una vista dedicada, ForEachStore, que se ocupaba de suscribirse solo a los cambios relevantes y de mantener la identidad de cada fila.

// Estilo previo, aún vigente en bases de código con WithViewStore
ForEachStore(store.scope(state: \.filas, action: \.filas)) { filaStore in
  FilaView(store: filaStore)
}

Con la observación integrada, el scope de una colección devuelve algo que ya es una colección de acceso aleatorio cuyos elementos conforman Identifiable, y por tanto el ForEach corriente de SwiftUI la acepta sin adaptadores. Ese es el motivo por el que ForEachStore fue quedando atrás: no porque hiciera algo mal, sino porque su trabajo —observar con grano fino y preservar identidad— pasó a hacerlo el sistema. Conocer las dos formas importa igual, porque cualquier código escrito antes de la migración usará la primera y ambas conviven sin conflicto en el mismo proyecto.

Los enlaces bidireccionales viajan por el mismo camino. Una fila con un campo de texto no necesita nada especial del padre: declara su store como @Bindable y deriva el binding de su propio estado, con la acción que corresponda.

struct FilaView: View {
  @Bindable var store: StoreOf<Fila>

  var body: some View {
    TextField("Título", text: $store.texto.sending(\.textoCambio))
  }
}

Ese binding escribe mediante una acción de la fila, que el scope envuelve con la identidad y forEach entrega al elemento correcto. Es decir: incluso el gesto más aparentemente directo de SwiftUI —teclear en un campo— sigue recorriendo el ciclo unidireccional completo y queda registrado como una acción que un test puede afirmar. No hay puerta trasera, ni en una fila ni en diez mil.

Qué gana la fila al tener store propio

El store por elemento no es una formalidad de plomería: compra cuatro propiedades concretas, y las cuatro se pierden a la vez en cuanto la celda vuelve a recibir un modelo y unas closures.

La primera propiedad es la que conviene verificar de inmediato, porque es la que delata cualquier fuga de contexto: si la vista de fila se puede arrancar sola, es que de verdad no depende del padre.

#Preview("Una fila, sin lista y sin padre") {
  FilaView(
    store: Store(initialState: Fila.State(id: UUID(), texto: "Aislada")) {
      Fila()
    }
  )
}

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

  var body: some View {
    List {
      ForEach(store.scope(state: \.filas, action: \.filas)) { filaStore in
        FilaView(store: filaStore)
      }
      .onDelete { offsets in store.send(.borrar(offsets)) }
      .onMove { origen, destino in store.send(.mover(origen, destino)) }
    }
  }
}

Repara en el reparto de responsabilidades del final. El toque sobre una fila es asunto de la fila y viaja por su store. Pero borrar y mover no son acciones de una fila: son operaciones sobre la colección, que solo el padre posee, y por eso se envían al store del padre con los índices que SwiftUI entrega. Esa frontera —lo que le pasa a un elemento contra lo que le pasa a la lista— es la que organiza la lección siguiente, y también la fuente del error más sutil del nivel, porque esos índices que llegan de onDelete hablan de lo que se ve en pantalla y no necesariamente de lo que hay en el estado.

flowchart TD
SP[Store del padre Lista] --> SC[scope sobre filas y accion dirigida]
SC --> S1[Store de la fila uno]
SC --> S2[Store de la fila dos]
SC --> S3[Store de la fila tres]
S1 --> V1[FilaView aislada]
S2 --> V2[FilaView aislada]
S3 --> V3[FilaView aislada]
V2 -->|send accion propia| SP
style SC fill:#89b4fa,color:#11111b