Operadores del body: `onChange`, `_printChanges` y los modificadores que envuelven

Un body compone en dos ejes perpendiculares y conviene no confundirlos nunca. El eje vertical es la lista: reducers hermanos que se ejecutan en secuencia sobre el mismo estado. El eje horizontal es el de los modificadores: métodos encadenados con punto que no modifican nada, sino que construyen un reducer nuevo con el anterior dentro, como capas de una cebolla. .ifLet ya lo hacía; onChange, _printChanges, dependency y signpost hacen lo mismo con otros propósitos. Entender que un modificador es un envoltorio —y no una configuración— aclara de golpe por qué su alcance es exactamente el elemento al que se pega, y por qué el orden en que los encadenas también cambia lo que ves.

El modificador es un reducer que envuelve a otro

Cuando escribes Reduce { ... }.onChange(of: \.filtro) { ... } no estás configurando el Reduce: estás llamando a un método del protocolo Reducer que devuelve un tipo nuevo —un struct genérico que guarda el reducer original como propiedad— y que a su vez conforma a Reducer. Al llegar una acción, el envoltorio ejecuta primero lo que tiene dentro y después aplica su propia aportación. Es el patrón decorador, pero resuelto en el sistema de tipos y sin una sola asignación en el montón.

De esa mecánica se deriva la regla de alcance que más desconcierta al principio: un modificador afecta solo al elemento al que está pegado, no a los que estén encima o debajo en el body. Si lo que quieres es envolver a todo el conjunto, necesitas un contenedor explícito.

// Alcance parcial: solo el segundo Reduce queda instrumentado.
var body: some ReducerOf<Self> {
  BindingReducer()
  Reduce { state, action in ... }
    ._printChanges()
}

// Alcance total: la cebolla envuelve la composicion entera.
var body: some ReducerOf<Self> {
  CombineReducers {
    BindingReducer()
    Reduce { state, action in ... }
  }
  ._printChanges()
}

CombineReducers no aporta comportamiento: agrupa una lista en un único valor para que tengas algo a lo que pegar el modificador. Es el equivalente al paréntesis en una expresión aritmética, y su necesidad es la mejor prueba de que los modificadores no son ajustes globales sino composición.

flowchart TD
A[accion] --> P[capa printChanges]
P --> O[capa onChange]
O --> R[Reduce base muta el estado]
R --> O2[onChange compara antes y despues]
O2 --> P2[printChanges imprime accion y diff]
P2 --> S[estado final y efectos]

onChange: reaccionar al cambio, no a la acción

onChange responde a una pregunta que un switch sobre acciones no sabe contestar bien: «haga lo que haga el usuario, si este valor del estado acaba cambiando, quiero recalcular aquello». Toma un key path —o una función de proyección— hacia un valor Equatable, ejecuta el reducer que envuelve, compara el valor antes y después, y solo si difieren corre el reducer que le pasas en la closure, que recibe el valor anterior y el nuevo.

var body: some ReducerOf<Self> {
  BindingReducer()
  Reduce { state, action in
    // logica propia
    return .none
  }
  .onChange(of: \.filtro) { anterior, nuevo in
    Reduce { state, _ in
      state.visibles = state.todos.filter { $0.coincide(con: nuevo) }
      return .none
    }
  }
}

La proyección puede ser cualquier función del estado, no solo un key path, de modo que también observas valores compuestos: .onChange(of: { [$0.filtro, $0.orden] }) dispara cuando cambia cualquiera de los dos, y .onChange(of: \.items.count) reacciona al tamaño de una colección sin comparar su contenido, que es bastante más barato.

Su virtud es que centraliza una invariante: da igual qué acción haya movido filtro —un binding, una respuesta de red, la restauración de un estado guardado—, la lista visible se recalcula siempre. Escribir esa misma garantía a mano obligaría a recordar el recálculo en cada rama del switch, y la memoria falla.

_printChanges: la lupa con guion bajo

_printChanges envuelve un reducer para que imprima, en cada acción, la acción recibida y el diff del estado calculado con swift-custom-dump: solo las líneas que cambiaron, con prefijos de más y menos como en un parche. Es la herramienta de diagnóstico más rentable de TCA, y también la más malinterpretada.

var body: some ReducerOf<Self> {
  Reduce { state, action in ... }
    ._printChanges()                 // accion mas diff completo
    // ._printChanges(.actionLabels) // solo la etiqueta de la accion
}

El guion bajo inicial es una convención formal de Point-Free, no un descuido: marca una API no cubierta por versionado semántico, que puede cambiar de firma o desaparecer en cualquier versión menor. Úsala mientras depuras y retírala antes de fusionar. El modo .actionLabels imprime solo el nombre del caso sin los valores asociados, y es el que quieres cuando el estado es grande, cuando el diff domina la consola o cuando el estado contiene datos personales que no deberían acabar en un registro. La implementación vive detrás de #if DEBUG, así que no penaliza una compilación de release, pero eso no es excusa para dejarla escrita.

Otros envoltorios: dependencias y medición

La misma mecánica sirve para dos necesidades muy distintas. dependency sobrescribe un valor del entorno solo para el subárbol envuelto, lo que permite que una parte de la app use un reloj o un generador de identificadores distinto del resto sin tocar nada global; transformDependency hace lo mismo con acceso mutable al valor existente, útil cuando quieres decorar en vez de sustituir. signpost, por su parte, emite marcas de os_signpost alrededor de cada ejecución del reducer, de modo que Instruments te muestra en la línea temporal cuánto tarda cada acción.

var body: some ReducerOf<Self> {
  Reduce { state, action in ... }
    .dependency(\.uuid, .incrementing)
    .signpost()
    .ifLet(\.$destino, action: \.destino) { Destino() }
}

Fíjate en que el encadenamiento también tiene orden: cada llamada envuelve el resultado de la anterior, así que signpost mide un reducer que ya incluye la sustitución de la dependencia, y ifLet gobierna un padre que ya está medido. Cuando dos modificadores observan el estado, encadenarlos al revés cambia lo que cada uno ve; cuando solo lo transforman, el orden es indiferente. Averiguar en cuál de los dos casos estás es parte del trabajo.