BindableAction y ViewAction: los dos protocolos que disciplinan la vista

Dos fuerzas tiran de la Action en direcciones opuestas. Los formularios empujan hacia la explosión: cada campo de texto, cada interruptor y cada deslizador reclama su propio caso, su rama en el switch y su test, y todos hacen exactamente lo mismo —asignar un valor a un campo—. La composición empuja hacia la protección: cuanto más rica es la Action, más casos existen que la vista jamás debería enviar y que, sin embargo, puede enviar. TCA responde a cada fuerza con un protocolo. BindableAction colapsa la explosión de setters en un único caso, y ViewAction sella la superficie que la interfaz alcanza. Son ortogonales, se usan juntos y resuelven problemas que ninguna otra parte de la arquitectura resuelve.

El coste oculto de un formulario

Escrito a mano, un formulario de tres campos produce tres casos idénticos en intención y distintos en tipo, tres ramas de una sola línea y tres tests que no verifican ninguna regla de negocio. Con diez campos, la Action deja de leerse como el catálogo de sucesos de la feature y pasa a leerse como la lista de propiedades de la struct, duplicada.

BindableAction sustituye todo eso por un único caso paramétrico que transporta, dentro de sí, el key path del campo afectado y su nuevo valor. BindingReducer es la hoja que aplica esa escritura sin que tú escribas una sola asignación.

@Reducer
struct Ajustes {
  @ObservableState
  struct State: Equatable {
    var nombre = ""
    var notificaciones = false
    var volumen = 0.5
  }

  enum Action: BindableAction {
    case binding(BindingAction<State>)
    case guardarPulsado
  }

  var body: some ReducerOf<Self> {
    BindingReducer()
    Reduce { state, action in
      switch action {
      case .binding(\.notificaciones):
        return .run { [on = state.notificaciones] _ in
          await notificaciones.actualizar(on)
        }
      case .binding:
        return .none
      case .guardarPulsado:
        return .none
      }
    }
  }
}

En la vista, @Bindable produce bindings directamente contra el Store, y cada escritura se traduce internamente en un envío del caso binding.

struct AjustesView: View {
  @Bindable var store: StoreOf<Ajustes>
  var body: some View {
    Form {
      TextField("Nombre", text: $store.nombre)
      Toggle("Notificaciones", isOn: $store.notificaciones)
      Slider(value: $store.volumen)
    }
  }
}

Lo notable es que la disciplina unidireccional no se rompe: el binding no muta el estado, envía una acción que el BindingReducer interpreta. La mutación sigue pasando por el único punto autorizado, y _printChanges sigue registrando cada edición como un suceso con nombre.

ViewAction: cerrar por compilador la puerta de la vista

La partición en view, _internal y delegate de la lección anterior es una convención que nada obliga a respetar: la vista puede seguir enviando ._internal(...) si le apetece. ViewAction convierte esa convención en una restricción verificada. El enum Action declara conformidad al protocolo y expone un caso view con su subenum; la macro @ViewAction(for:) dota a la vista de un método send que solo acepta valores de ese subenum.

@Reducer
struct Contador {
  @ObservableState
  struct State: Equatable { var cuenta = 0 }

  enum Action: ViewAction {
    case view(View)
    case _internal(Internal)

    enum View: Equatable {
      case incrementarPulsado
      case reiniciarPulsado
    }
    enum Internal: Equatable {
      case tickRecibido
    }
  }
}

@ViewAction(for: Contador.self)
struct ContadorView: View {
  let store: StoreOf<Contador>
  var body: some View {
    VStack {
      Text("\(store.cuenta)")
      Button("Mas") { send(.incrementarPulsado) }
      Button("Reiniciar") { send(.reiniciarPulsado) }
    }
  }
}

Escribir send(.tickRecibido) deja de compilar, y con ello desaparece toda una familia de errores: la vista que simula una respuesta de red, la que se salta la validación disparando directamente la acción interna que sigue al gesto, la que reenvía una delegate para provocar navegación desde abajo. Ninguna de esas rutas necesita ya vigilancia en revisión de código porque el tipo las prohíbe.

flowchart LR
F[Campos del formulario] --> B[caso binding]
B --> BR[BindingReducer escribe]
G[Gestos con logica] --> VA[subenum View]
VA --> RD[Reduce delibera]
BR --> ST[State]
RD --> ST
RD --> EF[Effect]

Los dos juntos, y cuándo no usar binding

Nada impide combinarlos: la Action conforma ambos protocolos, el caso binding se declara dentro del subenum View —que a su vez conforma BindableAction— y el BindingReducer se apunta a esa rama con BindingReducer(action: \.view). El resultado es una feature donde los campos del formulario cuestan cero casos y la vista no puede enviar nada más que sus propios gestos.

enum Action: BindableAction, ViewAction {
  case view(View)
  case _internal(Internal)

  enum View: BindableAction, Equatable {
    case binding(BindingAction<State>)
    case guardarPulsado
  }
  enum Internal: Equatable { case guardadoTerminado(Bool) }
}

var body: some ReducerOf<Self> {
  BindingReducer(action: \.view)
  Reduce { state, action in /* ... */ .none }
}