Bindable en la vista: conectar TextField, Toggle y Picker al store

Un control de SwiftUI no sabe nada de reducers: pide un Binding y escribe en él. Toda la elegancia del nivel se juega en cómo se fabrica ese Binding sin abrir una segunda puerta de mutación. La respuesta de TCA es que el propio Store sea la fuente de la proyección: declarado con @Bindable, expone bindings sobre las propiedades de su estado observable cuya lectura es directa y cuya escritura, en lugar de asignar, construye y envía el caso binding. Lo que la vista escribe se lee exactamente igual que un binding a un modelo, y lo que ocurre por debajo sigue siendo el ciclo unidireccional completo. Esta lección examina esa costura desde el lado de la interfaz.

La proyección $store.campo

@Bindable es una macro de SwiftUI, no de TCA: sirve para cualquier objeto observable y habilita la proyección con el símbolo del dólar sobre sus propiedades. TCA hace que Store sea observable y que su estado sea alcanzable por miembro dinámico, de modo que la combinación funciona sin ninguna pieza intermedia.

struct PerfilView: View {
  @Bindable var store: StoreOf<Perfil>

  var body: some View {
    Form {
      Section("Identidad") {
        TextField("Nombre", text: $store.nombre)
        TextField("Correo", text: $store.correo)
          .keyboardType(.emailAddress)
          .textInputAutocapitalization(.never)
      }
      Section("Preferencias") {
        Toggle("Recibir notificaciones", isOn: $store.notificaciones)
        Picker("Visibilidad", selection: $store.visibilidad) {
          ForEach(Visibilidad.allCases) { v in
            Text(v.titulo).tag(v)
          }
        }
        Slider(value: $store.volumen, in: 0...1)
        Stepper("Copias: \(store.copias)", value: $store.copias, in: 1...9)
      }
      Button("Guardar") { store.send(.guardarPulsado) }
    }
  }
}

Cuatro observaciones sobre este cuerpo. La lectura sin dólar —store.copias dentro de la interpolación— accede al valor y suscribe la vista a esa propiedad concreta. La lectura con dólar produce el binding. El botón no usa binding porque pulsar no es escribir un valor: es un suceso con nombre, y conserva su caso propio. Y el Picker exige que el tipo de la selección coincida exactamente con el de las etiquetas del tag, requisito de SwiftUI que no tiene nada que ver con TCA pero que produce el error más frecuente de esta lección: un Picker que no selecciona nada suele ser un tag con tipo distinto al de la propiedad.

Qué ocurre en una pulsación de tecla

Conviene tener el recorrido completo en la cabeza, porque explica a la vez por qué esto es seguro y por qué el orden del body importaba tanto en la lección anterior.

sequenceDiagram
participant U as Usuario
participant TF as TextField
participant B as Binding proyectado
participant S as Store
participant BR as BindingReducer
U->>TF: escribe una letra
TF->>B: asigna el texto nuevo
B->>S: send del caso binding con key path y valor
S->>BR: entrega la accion
BR->>S: escribe la propiedad del estado
S->>TF: la observacion invalida y redibuja
TF->>U: muestra el texto actualizado

El punto crítico es que el set del binding no escribe en el estado: envía. La escritura ocurre después, dentro del reducer, en el único lugar autorizado. Por eso una edición aparece en _printChanges como cualquier otra acción, por eso es interceptable, y por eso un TestStore puede afirmar sobre ella. La vista nunca sostiene una copia mutable del estado; sostiene una lente de lectura y un canal de envío que la sintaxis disfraza de propiedad mutable.

De ahí se sigue una regla práctica sobre cuándo declarar @Bindable y cuándo no. La macro solo hace falta si la vista va a proyectar; una vista que únicamente lee y envía acciones con nombre no la necesita y puede declarar el store como constante, lo cual documenta de un vistazo que ahí no hay campos editables.

struct ResumenView: View {
  let store: StoreOf<Perfil>            // solo lee y envia
  var body: some View {
    VStack {
      Text(store.nombre)
      Button("Editar") { store.send(.editarPulsado) }
    }
  }
}

Cuando el tipo del control no encaja

A veces el control pide un tipo distinto del que guarda el estado: un campo de texto que edita un número, un Toggle sobre un valor opcional, un selector cuyo dominio es más rico. Hay tres respuestas, y elegir la correcta es el juicio profesional de esta lección.

La primera es cambiar el estado para que guarde lo que el usuario realmente edita. Un campo de importe se edita como texto, así que el estado guarda un String y la conversión a número vive en la validación o en el momento del envío. Esta es casi siempre la respuesta buena, porque modela el formulario como lo que es —una zona de trabajo textual— y evita el borrado de lo que el usuario está escribiendo a medias.

La segunda es usar el formateador del propio control, que SwiftUI ofrece de serie y que resuelve el caso numérico sin conversiones manuales.

TextField("Importe", value: $store.importe, format: .number)
DatePicker("Fecha", selection: $store.fecha, displayedComponents: .date)

La tercera es derivar un binding a partir del proyectado, transformando lectura y escritura. Es legítima porque la escritura sigue terminando en un envío, pero conviene usarla solo cuando la transformación es total y sin pérdida.

// Toggle sobre un opcional: presente o ausente
Toggle("Con recordatorio", isOn: Binding(
  get: { store.recordatorio != nil },
  set: { store.send(.recordatorioActivado($0)) }
))

Fíjate en que este último caso ya no es un binding de campo sino un gesto con significado —activar algo, no escribir un valor— y por eso vuelve a merecer un caso con nombre en pasado. La frontera es exactamente esa: si la transformación cambia el significado, has salido del territorio del binding.

Un cuarto caso merece mención aparte porque se presenta constantemente y confunde: el control que edita una propiedad de una feature hija. La proyección no atraviesa fronteras de features, así que no intentes escribir una ruta larga desde el padre. Lo correcto es rebanar el store hacia el hijo y que la vista del hijo, declarada también con @Bindable, proyecte sobre su propio estado. Cada feature valida y escribe lo suyo, y el padre se entera por delegación si necesita enterarse.