El flujo unidireccional: estado abajo, acciones arriba

Si hubiera que reducir TCA a una sola frase, sería esta: el estado baja, las acciones suben. El Store entrega el estado a la vista, que se dibuja como una función pura de ese estado; y cuando el usuario interactúa, la vista no cambia nada por su cuenta, sino que envía una acción de vuelta al Store, único lugar con permiso para provocar el cambio. El resultado es un bucle cerrado que gira siempre en el mismo sentido —el mismo ciclo que Elm popularizó con su trío vista, mensaje y actualización— y esa unidireccionalidad no es un capricho estético: es lo que garantiza que exista un solo camino por el que el estado puede cambiar, y por tanto un solo lugar donde buscar cuando algo va mal.

Estado abajo: la vista es una función del estado

La primera mitad del bucle es la bajada. La vista no guarda estado propio sobre la feature: recibe un StoreOf<Contador> y lee de él todo lo que necesita pintar. Cuando el estado del Store cambia, la vista se recalcula, porque en SwiftUI una vista es, por definición, una función de su estado. Esto convierte el renderizado en algo trivialmente predecible: dado un State, la vista siempre pinta lo mismo, sin importar cómo se llegó a ese estado. No hay historia oculta ni mutaciones parciales; la pantalla es un reflejo directo del valor actual.

struct ContadorView: View {
  let store: StoreOf<Contador>

  var body: some View {
    VStack {
      Text("\(store.cuenta)")        // estado abajo: la vista LEE del store
      HStack {
        Button("-") { store.send(.decremento) }
        Button("+") { store.send(.incremento) }
      }
    }
  }
}

Acciones arriba: la vista no muta, envía

La segunda mitad es la subida. Cuando el usuario pulsa un botón, la vista no escribe store.cuenta += 1 —eso sería mutar el estado desde fuera del reducer, exactamente lo que la arquitectura prohíbe—. En su lugar llama a store.send(.incremento): informa de un hecho y deja que el Reducer decida. El estado es de solo lectura desde la vista; la única forma de cambiarlo es enviar una acción y esperar a que el bucle dé la vuelta. Esta asimetría —leer directo, escribir solo por acción— es la esencia del flujo unidireccional, y es lo que impide que el estado cambie por caminos que nadie vigila.

Podría objetarse que los formularios rompen esto, porque un TextField necesita un binding bidireccional para funcionar. TCA lo resuelve sin traicionar el principio: el binding no muta el estado directamente, sino que cada tecleo se traduce en una acción que sube al Store como cualquier otra. Con @Bindable sobre el store y un BindingReducer en la feature, el ciclo se mantiene intacto aunque la sintaxis parezca un binding normal.

struct FormularioView: View {
  @Bindable var store: StoreOf<Formulario>

  var body: some View {
    Form {
      // Parece un binding normal, pero cada cambio ENVIA una accion al store.
      TextField("Nombre", text: $store.nombre)
      Toggle("Recordarme", isOn: $store.recordar)
    }
  }
}

El ciclo cerrado: de la acción al estado y de vuelta

Uniendo las dos mitades aparece el bucle completo, y es idéntico al de Elm. La vista envía una Action al Store; el Store se la pasa al Reducer; el Reducer muta el State y quizá devuelve un Effect; el Store guarda el nuevo estado, y como la vista es función de ese estado, se redibuja. Si el reducer devolvió un efecto, este corre por fuera y, al terminar, envía una nueva Action que vuelve a entrar por el mismo punto. El bucle nunca se salta pasos ni cambia de sentido: toda información que sube es una acción, toda información que baja es estado, y en medio siempre está el reducer.

flowchart LR
VIEW[Vista] -->|send Action| STORE[Store]
STORE -->|pasa la accion| REDUCER[Reducer]
REDUCER -->|muta| STATE[State]
STATE -->|estado abajo| VIEW
REDUCER -->|devuelve| EFFECT[Effect]
EFFECT -->|nueva Action| STORE
style VIEW fill:#89b4fa,color:#11111b
style STORE fill:#cba6f7,color:#11111b
style REDUCER fill:#f9e2af,color:#11111b
style STATE fill:#a6e3a1,color:#11111b
style EFFECT fill:#f38ba8,color:#11111b