No hacer nada, enviar de inmediato y combinar: el álgebra de los efectos

Si los efectos son valores, entonces se combinan; y si se combinan, hay un álgebra. La de TCA es deliberadamente pequeña: un elemento neutro que significa no queda nada por hacer, un constructor que inyecta una acción de inmediato, y dos combinadores que juntan varios efectos en uno solo, uno en paralelo y otro en secuencia. Cuatro piezas bastan porque cada una expresa una relación temporal distinta entre trabajos, y toda la coreografía asíncrona de una feature se escribe eligiendo bien entre esas relaciones. Conocerlas de memoria no es erudición: es la diferencia entre una pantalla que arranca sus tres suscripciones a la vez y otra que las encadena sin querer y se queda esperando la primera para siempre.

El neutro: declarar que no queda trabajo

Cada rama de tu switch tiene que devolver un efecto, y la mayoría devuelve .none. No es un relleno sintáctico: es una afirmación con contenido. Dice que la transición terminó dentro del reducer, que el estado ya refleja todo lo que esa acción provoca y que el store no tiene nada que arrancar. Que el compilador te obligue a escribirlo en cada rama es un acierto de diseño, porque convierte en explícita una decisión que en otras arquitecturas se toma por omisión.

case let .nombreEditado(texto):
  state.nombre = texto
  state.valido = !texto.isEmpty
  return .none

.none es además el elemento neutro del álgebra: fusionarlo o encadenarlo con cualquier efecto devuelve ese efecto intacto. Esa propiedad tiene un uso muy práctico cuando construyes efectos condicionalmente, porque te permite escribir la rama vacía sin casos especiales.

var extra: Effect<Action> = .none
if state.debeSincronizar {
  extra = .run { send in
    try await sincronizador.sincronizar()
    await send(.sincronizado)
  }
}
return .merge(.run { send in await send(.listo) }, extra)

.send: la conversación entre padre e hijo

.send(.accion) construye un efecto que emite esa acción de inmediato, sin esperar a nada. Su lugar legítimo es estrecho y conviene decirlo pronto: sirve para que una feature hija le hable a su padre —el patrón de las acciones de delegado— o para que un padre empuje una acción a un hijo tras una presentación. Fuera de esa conversación, casi siempre es la herramienta equivocada.

// En el hijo: la unica forma legitima de hablar hacia arriba
case .guardarPulsado:
  state.guardado = true
  return .send(.delegado(.seGuardo(state.item)))

// En el padre: escucha ese caso y decide que significa para el
case let .editor(.presented(.delegado(.seGuardo(item)))):
  state.items[id: item.id] = item
  state.editor = nil
  return .none

Aquí la vuelta por el store no es un coste sino el mecanismo mismo: la acción de delegado es un hecho real que cruza la frontera entre dos features, y merece aparecer en la traza y en los tests como una acción recibida más. El hijo no sabe qué hará el padre con ese hecho —quizá guardarlo, quizá también cerrar la hoja, quizá nada—, y esa ignorancia es lo que mantiene al hijo reutilizable.

El mal uso clásico es emplearlo para reutilizar lógica: tienes un caso .refrescar que ya hace lo que quieres y desde .alAparecer devuelves .send(.refrescar) para no repetirte. Parece elegante y es peor de lo que parece. Añade una vuelta completa por el store —y por tanto una acción intermedia que aparecerá en los tests y en los registros—, hace la traza más difícil de leer, y acopla dos casos que quizá mañana no quieran hacer exactamente lo mismo. La reutilización correcta es la de siempre: extrae un método que devuelva el efecto y llámalo desde ambas ramas.

private func cargar(_ state: inout State) -> Effect<Action> {
  state.cargando = true
  return .run { send in await send(.respuesta(...)) }
}

case .alAparecer: return cargar(&state)
case .refrescar:  return cargar(&state)

.merge y .concatenate: paralelo y secuencia

Los dos combinadores fusionan varios efectos en uno solo, y se diferencian únicamente en la relación temporal que garantizan. .merge los arranca todos a la vez y funde sus acciones según van llegando, sin orden prometido entre efectos distintos. .concatenate los ejecuta uno tras otro: el segundo no empieza hasta que el primero ha terminado del todo.

flowchart LR
S[Store recibe el Effect combinado] --> MG[merge arranca A y B a la vez]
MG --> AB[acciones entrelazadas segun llegan]
S --> CC[concatenate arranca solo A]
CC --> CB[al terminar A arranca B]
CB --> OR[acciones en orden estricto]
style MG fill:#89b4fa,color:#11111b
style CC fill:#f9e2af,color:#11111b

El caso de uso arquetípico de .merge es la aparición de una pantalla que necesita varias cosas independientes: cargar datos, suscribirse a notificaciones y arrancar un reloj. Nada de eso depende de lo demás, así que encadenarlo sería regalar latencia.

case .alAparecer:
  return .merge(
    .run { send in await send(.datos(try await cliente.cargar())) },
    .run { send in
      for await n in centro.notificaciones() { await send(.notificacion(n)) }
    }
    .cancellable(id: CancelID.notificaciones),
    .run { send in
      for await _ in clock.timer(interval: .seconds(1)) { await send(.tick) }
    }
    .cancellable(id: CancelID.reloj)
  )

.concatenate, en cambio, se reserva para cuando el orden es parte del significado: guardar y solo después recargar, o encadenar pasos de una animación que deben verse uno detrás de otro.

case .guardarYRecargar:
  let borrador = state.borrador
  return .concatenate(
    .run { send in
      try await api.guardar(borrador)
      await send(.guardado)
    },
    .run { send in
      await send(.datos(try await api.cargar()))
    }
  )

Aquí el orden no es una preferencia estética: recargar antes de que el guardado haya terminado devolvería datos viejos y pintaría en pantalla justo lo contrario de lo que el usuario acaba de hacer. Pagas la latencia de la suma porque la alternativa es una condición de carrera con consecuencias visibles. Ambos combinadores existen también como método sobre un efecto, con .merge(with:) y .concatenate(with:), útiles cuando construyes el efecto por acumulación en varias ramas de un condicional.