Las acciones cuentan qué pasó, no qué hacer

Toda arquitectura unidireccional descansa sobre un reparto de poderes: la vista observa y testifica, el reducer delibera y muta, el runtime ejecuta. La Action es la frontera exacta donde ese reparto se firma o se traiciona, y se traiciona con una sola palabra mal elegida. Un caso llamado cargarDatos es una orden: quien lo envía ya resolvió que hay que cargar, y el reducer queda degradado a ejecutor obediente. Un caso llamado alAparecer es un hecho: la vista levanta acta de lo ocurrido y el reducer conserva íntegra la facultad de decidir si eso implica cargar, no hacer nada o cancelar lo anterior. La diferencia parece cosmética; es constitucional.

Testificar frente a ordenar

Compara dos versiones del mismo dominio. La primera está escrita como una lista de métodos disfrazada de enum; la segunda, como un registro de sucesos.

// Imperativa: cada caso es una orden
enum Action {
  case cargarDatos
  case guardar
  case mostrarAlerta(String)
  case navegarADetalle(Articulo.ID)
}

// Declarativa: cada caso es un hecho
enum Action {
  case alAparecer
  case guardarPulsado
  case guardadoFallo(String)
  case filaPulsada(Articulo.ID)
}

La lista imperativa contiene decisiones ya tomadas. mostrarAlerta presupone que la alerta debe mostrarse, y por tanto alguien —la vista, un efecto, otra feature— tuvo que evaluar la condición antes de enviarla. La lista declarativa contiene únicamente observaciones: el guardado falló con un mensaje, y si eso merece una alerta, un banner o un reintento silencioso lo dictamina el reducer, que es el único lugar donde esa política puede vivir sin duplicarse.

El paralelismo con el modelado de dominios es exacto. En event sourcing y en CQRS se distingue con precisión entre un comando —una petición en imperativo que el sistema puede rechazar— y un evento —un hecho en pasado que ya ocurrió y no admite negociación—. La Action de TCA es un evento, nunca un comando. Es un registro append-only de lo que sucedió, y por eso el reducer se comporta como el intérprete de ese registro y no como su destinatario.

La consecuencia práctica más inmediata es la reutilización. Un hecho admite respuestas distintas en contextos distintos sin cambiar de nombre: alAparecer puede significar cargar la primera vez, refrescar si los datos caducaron o no hacer absolutamente nada si ya hay una petición en vuelo, y las tres políticas conviven en la misma rama del reducer sin que la vista sepa cuál se aplicó.

case .alAparecer:
  guard !state.cargando, state.articulos.isEmpty else { return .none }
  state.cargando = true
  return .run { send in
    await send(.datosRecibidos(try await api.articulos()))
  }

Con cargarDatos esa deliberación no cabe: el nombre afirma que hay que cargar, y toda condición para no hacerlo tendría que evaluarse antes del envío, es decir, fuera de la única función que el TestStore observa.

La fuga de decisiones hacia la vista

Cuando un caso es una orden, la lógica que justifica esa orden tiene que ejecutarse antes del envío, y el único sitio disponible suele ser el cuerpo de la vista. Ahí empieza la erosión: aparece un if en el botón, luego un cálculo, luego una condición compuesta, y de pronto la vista contiene reglas de negocio que ningún TestStore puede alcanzar.

// Fuga: la vista decide
Button("Guardar") {
  if store.nombre.isEmpty {
    store.send(.mostrarAlerta("El nombre es obligatorio"))
  } else {
    store.send(.guardar)
  }
}

// Correcto: la vista testifica, el reducer decide
Button("Guardar") { store.send(.guardarPulsado) }

La versión corregida no es más corta por casualidad. La vista dejó de conocer la regla de validación, y esa regla pasó a una rama del switch que el test puede recorrer sin simulador. Toda condición que sobreviva dentro de una vista es una porción de dominio inaccesible para la verificación.

flowchart LR
U[Usuario pulsa] --> V[Vista testifica el hecho]
V --> A[Action guardarPulsado]
A --> R[Reducer delibera]
R --> S[State nuevo]
R --> E[Effect]
E --> A2[Action guardadoFallo]
A2 --> R

Convención de nombres: sujeto, suceso, tiempo pasado

La regla operativa de Point-Free se enuncia en una línea: nombra el caso por lo que ocurrió, incluyendo quién o qué lo provocó, y en tiempo pasado o participio. El nombre resultante suele leerse como un titular breve.

Hay una prueba empírica muy fiable. Activa _printChanges en el reducer y lee la traza de una sesión: si la secuencia de acciones se deja narrar como la crónica de lo que hizo el usuario y lo que respondió el sistema, los nombres son correctos. Si la traza parece el registro de llamadas a un objeto, los nombres son órdenes y la arquitectura ya está filtrando decisiones.

Refactorizar un enum imperativo

El refactor es mecánico y se hace caso a caso, sin big bang. Para cada orden, identifica el suceso real que la provocaba y renómbrala por él; después traslada al reducer la condición que se había quedado en la vista.

case .guardarPulsado:
  guard !state.nombre.isEmpty else {
    state.alerta = .nombreObligatorio
    return .none
  }
  state.guardando = true
  return .run { [perfil = state.perfil] send in
    await send(.guardadoTerminado(Result { try await api.guardar(perfil) }))
  }

Observa que el efecto no devuelve una orden como .mostrarExito, sino otro hecho: guardadoTerminado con su resultado. La regla se aplica igual a las acciones que nacen del sistema que a las que nacen del dedo del usuario. Una vez completado el barrido, el enum entero se lee como el catálogo cerrado de lo que puede pasarle a la feature, y ese catálogo es exactamente el guion que tus tests van a representar.

El resultado se aprecia mejor en el test que en el reducer. Un caso con nombre de hecho produce una prueba que se lee como el acta de una sesión, con los envíos correspondiendo a lo que hizo el usuario y las recepciones a lo que devolvió el mundo.

await store.send(.guardarPulsado) { $0.guardando = true }
await store.receive(\.guardadoTerminado.success) {
  $0.guardando = false
  $0.ultimoGuardado = fecha
}

Hay un último matiz que evita un malentendido frecuente. Nombrar en pasado no obliga a inventar participios forzados para todo: lo esencial no es la morfología del verbo sino que el caso describa un suceso y no una consecuencia. alAparecer, filaPulsada y respuestaRecibida cumplen la regla aunque su forma gramatical difiera, porque ninguno prejuzga qué debe hacer el reducer. Cuando dudes entre dos nombres, elige el que un observador externo podría haber escrito sin conocer tu código: si para nombrar el caso necesitas saber cómo reacciona la feature, has vuelto a codificar la decisión en el nombre.