BindableAction y BindingReducer: la acción genérica y el reducer que la aplica

El truco que colapsa doce casos en uno no es magia de macros: es una aplicación disciplinada de dos ideas que Swift ya tenía. La primera es que un key path escribible es un valor de primera clase, así que la identidad del campo a escribir puede viajar dentro de una acción en lugar de codificarse en su nombre. La segunda es que un reducer es un valor componible, así que la lógica de aplicar esa escritura puede vivir en una hoja reutilizable colocada al principio del body. BindableAction formaliza la primera, BindingReducer implementa la segunda, y de su encaje sale una feature donde añadir un campo al formulario no toca el enum ni el switch.

El protocolo y el valor que transporta

BindableAction es un protocolo con un único requisito: el tipo debe ofrecer una manera de construirse y descomponerse a partir de una escritura sobre el estado. En la práctica se satisface declarando un caso llamado binding cuya carga es un BindingAction parametrizado por el State de la feature.

@Reducer
struct Perfil {
  @ObservableState
  struct State: Equatable {
    var nombre = ""
    var correo = ""
    var notificaciones = false
    var visibilidad: Visibilidad = .privado
  }

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

  var body: some ReducerOf<Self> {
    BindingReducer()
    Reduce { state, action in
      switch action {
      case .binding:
        return .none
      case .guardarPulsado:
        return .run { [datos = state] _ in try await api.guardar(datos) }
      }
    }
  }
}

Lo que hay dentro de un BindingAction no es un par de valores sueltos sino una escritura encapsulada: un key path escribible desde el State hasta una propiedad concreta y el nuevo valor de esa propiedad, ambos capturados con sus tipos exactos y ocultos tras una clausura que sabe aplicarse sobre una instancia. El tipo compuesto sigue siendo Equatable —compara el key path y el valor— y sigue siendo imprimible, de modo que las dos garantías que hacían útil un enum con nombres explícitos sobreviven intactas: puedes afirmar sobre una edición concreta en un test y puedes verla identificada en la traza.

El orden en el body no es cosmético

BindingReducer es una hoja como cualquier otra: recibe estado y acción, y devuelve un efecto. Su cuerpo hace una sola cosa —si la acción es el caso binding, aplicar la escritura que transporta— y para todo lo demás devuelve .none. Como los reducers de un body se ejecutan en secuencia sobre el mismo estado, su posición decide qué ve el reducer siguiente.

// Correcto: cuando tu Reduce corre, el valor nuevo YA esta en el estado
var body: some ReducerOf<Self> {
  BindingReducer()
  Reduce { state, action in
    switch action {
    case .binding(\.correo):
      state.correoValido = state.correo.contains("@")
      return .none
    default:
      return .none
    }
  }
}

// Incorrecto: tu Reduce lee el valor ANTERIOR, la escritura aun no ocurrio
var body: some ReducerOf<Self> {
  Reduce { state, action in /* ... */ }
  BindingReducer()
}

Con BindingReducer primero, tu lógica observa el estado ya actualizado y puede razonar sobre él con naturalidad: comprobar la longitud del texto recién escrito, decidir si el formulario está completo, disparar una búsqueda con el término actual. Con el orden invertido lees el valor previo, lo cual no es un error de compilación sino una discrepancia de un tick que se manifiesta como una validación que siempre va un carácter por detrás. Es uno de los fallos más desconcertantes de este nivel porque todo parece correcto y el síntoma es sutil.

sequenceDiagram
participant V as Vista
participant S as Store
participant BR as BindingReducer
participant R as Reduce propio
V->>S: send binding con key path y valor
S->>BR: entrega la accion
BR->>BR: escribe la propiedad del estado
BR->>S: devuelve none
S->>R: entrega la misma accion
R->>R: lee el estado ya actualizado
R->>S: devuelve efecto o none

Cuando la Action está particionada

En features maduras la Action suele estar dividida por origen, con un subenum para lo que la vista puede enviar y otros para lo interno y lo delegado. El caso binding pertenece conceptualmente a la vista, así que vive dentro de ese subenum, y el BindingReducer necesita saber dónde buscarlo. Para eso acepta un key path que lo dirige a la rama correcta.

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

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

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

El subenum conforma BindableAction y el BindingReducer se apunta a él. La regla mental es simple: el reducer de binding se coloca en el mismo nivel donde vive el State que va a escribir, y el key path indica el camino hasta el caso que lo transporta. Si el enum externo no conforma el protocolo, ningún compilador te obliga a nada raro: basta con que el subenum lo haga y con que el BindingReducer reciba la ruta.