Reaccionar a un campo concreto: interceptar el binding para validar o disparar efectos

La objeción llega siempre en el mismo momento: si todos los campos envían la misma acción, se ha perdido la capacidad de reaccionar a uno en particular. Es falsa, y entender por qué es falsa es entender qué se hizo realmente en las lecciones anteriores. La identidad del campo no desapareció al colapsar los casos; se mudó del nombre del símbolo a la carga del mensaje, donde sigue siendo un valor tipado, comparable y —esto es lo que faltaba— coincidible por patrón. Filtrar por campo dentro del caso binding no solo recupera todo lo que parecía perdido, sino que lo hace mejor: el filtro es explícito, aparece solo donde hay lógica de verdad, y los campos que no la tienen no ensucian el switch con ramas vacías.

Filtrar por key path

El caso binding admite coincidencia de patrón con el key path del campo afectado. La rama específica se coloca antes de la genérica, y el compilador sigue exigiendo exhaustividad, de modo que ninguna edición queda sin tratar.

var body: some ReducerOf<Self> {
  BindingReducer()
  Reduce { state, action in
    switch action {
    case .binding(\.correo):
      state.correoValido = Validador.correo(state.correo)
      return .none

    case .binding(\.notificaciones):
      return .run { [activo = state.notificaciones] _ in
        await self.notificaciones.actualizar(activo)
      }

    case .binding(\.pais):
      state.provincia = nil
      state.provincias = []
      return .run { [pais = state.pais] send in
        await send(.provinciasLlegaron(try await self.api.provincias(pais)))
      }

    case .binding:
      return .none

    case let .provinciasLlegaron(lista):
      state.provincias = lista
      return .none
    }
  }
}

Tres reacciones de naturalezas distintas conviven sin fricción. La primera es pura: deriva un valor a partir del recién escrito. La segunda es un efecto sin respuesta: notifica al mundo exterior y no espera nada. La tercera es la más interesante porque combina las dos y añade una invalidación en cascada: al cambiar el país, la provincia elegida deja de tener sentido y se limpia en el mismo tick, antes de que la petición vuelva. Ese saneamiento inmediato es lo que evita el estado incoherente que aparecería si esperaras a la respuesta para limpiar.

Recuerda que todo esto solo funciona con BindingReducer colocado antes: cuando tu rama corre, state.correo ya contiene la letra que el usuario acaba de teclear. Si lees el valor anterior, revisa el orden del body antes de sospechar de cualquier otra cosa.

Efectos disparados por tecleo

El caso más común y más delicado es una edición que dispara una petición: un buscador que consulta mientras se escribe, un campo de usuario que comprueba disponibilidad, un formulario que autoguarda. Aquí el binding se encuentra de frente con todo lo aprendido sobre efectos, porque teclear genera decenas de acciones por segundo y cada una podría abrir una petición.

private enum CancelID { case busqueda }

case .binding(\.termino):
  guard state.termino.count >= 3 else {
    state.resultados = []
    return .cancel(id: CancelID.busqueda)
  }
  return .run { [termino = state.termino] send in
    await send(.resultadosLlegaron(try await self.api.buscar(termino)))
  }
  .debounce(id: CancelID.busqueda, for: .milliseconds(300), scheduler: self.reloj)

Cada pieza responde a un fallo concreto. El guardia de longitud mínima evita disparar contra el servidor con una sola letra y, sobre todo, cancela explícitamente lo que hubiera en vuelo cuando el usuario borra hasta quedar por debajo del umbral: sin ese cancel, una respuesta tardía repoblaría una lista que debía estar vacía. El debounce con identificador estable convierte una ráfaga de pulsaciones en una sola petición tras la pausa, y como comparte identificador con la cancelación, ambas operan sobre el mismo canal. El reloj es una dependencia inyectada, de modo que el test avanza el tiempo en lugar de esperarlo y la prueba tarda milisegundos.

flowchart TD
T[Tecla en el campo] --> BA[Accion binding con key path]
BA --> BR[BindingReducer escribe el estado]
BR --> SW[Coincidencia por key path]
SW -->|campo sin logica| N[none]
SW -->|campo derivado| D[Actualizar estado derivado]
SW -->|campo con dependencia| C[Limpiar cascada y pedir]
SW -->|campo de busqueda| E[Debounce y cancelacion]
E --> R[Respuesta llega como accion propia]
C --> R
R --> ST[Estado coherente]
D --> ST
style ST fill:#a6e3a1,color:#11111b

El límite: cuándo el campo reclama su propio caso

El patrón de intercepción es tan cómodo que invita a abusar de él. Conviene fijar el criterio antes de que el abuso se instale, y el criterio es semántico, no técnico.

Un binding es correcto cuando la interacción significa literalmente el usuario dejó este campo con este valor. Deja de serlo en cuanto el gesto significa algo más: un interruptor que arranca una migración de datos, un selector que reinicia una sesión, una casilla que acepta condiciones legales. En esos casos la traza es el árbitro. Si al leer el registro de acciones necesitas saber qué ocurrió y ver una escritura de campo no te lo dice, ese gesto merecía un nombre.

// Binding legitimo: el usuario esta editando un valor
case .binding(\.nombre):
  return .none

// Mal olor: el gesto significa mucho mas que escribir un valor
case .binding(\.modoAvanzado):
  return .run { _ in await self.migrador.reconstruirIndice() }

// Mejor: el suceso tiene nombre y la traza lo cuenta
case .modoAvanzadoActivado:
  state.modoAvanzado = true
  return .run { _ in await self.migrador.reconstruirIndice() }

Hay además un aviso de rendimiento: una rama de binding que hace trabajo caro se ejecuta en cada pulsación de tecla. Filtrar por longitud, aplicar debounce y mantener el trabajo síncrono trivial no son optimizaciones prematuras en este punto concreto, son la condición para que el formulario no vaya a tirones.