Acciones como setters: el olor que delata la pérdida del dominio

Abre un slice cualquiera y lee solo los nombres de sus reducers. Si lo que encuentras es setNombre, setEmail, setCargando, setError, setPaso y setVisible, acabas de diagnosticar sin necesidad de leer una línea de lógica: ese slice no describe qué le ocurre a tu aplicación, describe qué campos tiene. Es una traducción mecánica de la forma del estado a una interfaz de escritura, campo por campo, y su efecto es reducir Redux a un objeto mutable con ceremonia: dispones de un dispatch que hace exactamente lo que haría una asignación, con más pasos intermedios y ninguna de las ventajas por las que aceptaste esos pasos. El olor es fácil de detectar y difícil de valorar, porque el código funciona y nadie sabe señalar qué falta. Lo que falta es el dominio: en algún punto de la traducción se perdió la información sobre por qué el estado cambia, y esa información era todo el producto.

Eventos frente a órdenes

La distinción que organiza todo este asunto es antigua y no es de Redux: una acción puede ser un evento, que informa de algo que ya sucedió, o una orden, que pide que algo suceda. Las dos son estructuras de datos idénticas y semánticamente opuestas. formularioEnviado es un evento: relata un hecho consumado, no admite negociación, y lo que cada parte del sistema haga con él es asunto suyo. setCargando es una orden dirigida a un campo concreto: no dice qué pasó, dice qué escribas, y presupone que quien la emite sabe cuál debe ser el estado resultante.

El Flux original y Redux se diseñaron alrededor del primer significado, y de ahí viene la convención del tiempo pasado que tantos equipos tratan como una preferencia estilística. No lo es. Nombrar en pasado obliga a saber qué ocurrió antes de escribir el reducer, y esa obligación es el mecanismo que impide que la lógica de negocio se filtre al componente. Cuando un componente despacha setCargando(true), setError(null) y luego setUsuarios(datos), la secuencia correcta de esas tres escrituras es conocimiento de dominio que ahora vive en el componente, disperso y sin nombre. Cuando despacha usuariosSolicitados y después usuariosRecibidos, ese conocimiento vive en el reducer, que es el único sitio donde puede testearse sin montar una vista.

// Setters: el componente conoce la forma del estado y orquesta la secuencia.
dispatch(setCargando(true))
dispatch(setError(null))
const datos = await api.usuarios()
dispatch(setUsuarios(datos))
dispatch(setCargando(false))

// Eventos: el componente relata, el reducer decide la forma resultante.
dispatch(usuariosSolicitados())
const datos = await api.usuarios()
dispatch(usuariosRecibidos(datos))

Conviene notar además dónde queda el conocimiento sobre la forma del estado en cada versión. Con setters, el componente sabe que existe un campo llamado cargando, otro llamado error y otro llamado usuarios, y sabe en qué orden hay que escribirlos; ese conocimiento se repite en cada sitio que despacha la secuencia, de modo que renombrar un campo o añadir un cuarto obliga a visitar todos. Con eventos, el componente solo sabe qué ocurrió, y la forma del estado queda encerrada en el slice, que es el único que puede cambiarla. La diferencia se paga la primera vez que hay que añadir un contador de reintentos o una marca de tiempo a esa transición: en un caso se toca un reducer, en el otro se busca en toda la base de código.

Fíjate en lo que la segunda versión gana además de brevedad: entre la primera y la segunda línea de la versión con setters existe un instante en el que el estado tiene cargando en verdadero y el error todavía sin limpiar. Ese estado intermedio es visible para los suscriptores, aparece en el historial y puede renderizarse. Cada despacho adicional multiplica los estados intermedios posibles, y varios de ellos representan situaciones que tu dominio considera imposibles. Una sola acción que produce la transición completa no puede ser interrumpida a medias: la atomicidad no es un detalle de rendimiento, es la garantía de que los estados imposibles no existen ni siquiera durante un instante.

Las cuatro capacidades que desaparecen

La primera tarjeta tiene una consecuencia práctica que se aprecia el día que llega un informe de error. Con eventos, la secuencia de acciones exportada desde las DevTools es un guion reproducible: la pegas en tu entorno, la reproduces sobre el estado inicial y obtienes exactamente el fallo del usuario, porque cada línea describe algo que ese usuario hizo. Con setters, esa misma secuencia describe el resultado y no la causa, así que reproducirla te lleva al estado final sin pasar por el camino que lo produjo, y precisamente el camino era lo que querías examinar. El historial deja de ser una grabación y se convierte en un volcado.

La segunda tarjeta es la que más consecuencias arquitectónicas tiene y la que menos se ve al principio, así que conviene desarrollarla. El dispatch de Redux no es una llamada a una función: es una publicación en un canal que todos los reducers escuchan. Esa es la razón por la que combineReducers pasa cada acción a todos sus hijos, y de ahí sale la capacidad de que un mismo hecho produzca efectos en partes del estado que no se conocen entre sí. Cuando llega sesionCerrada, el slice de sesión borra el token, el de carrito se vacía, el de notificaciones se limpia y el de caché se invalida, sin que ninguno tenga que saber de los otros ni que exista un coordinador. Un setter destruye esa propiedad por construcción: su nombre menciona un campo, así que solo un reducer puede atenderlo con sentido, y el sistema de publicación queda reducido a una invocación con pasos de más. Dicho de forma memorable: un setter convierte un canal de publicación en una llamada a procedimiento, y paga el precio del canal sin quedarse con su beneficio.

flowchart LR
E[evento sesion cerrada] --> S1[slice sesion borra el token]
E --> S2[slice carrito se vacia]
E --> S3[slice avisos se limpia]
E --> S4[slice cache se invalida]
T[setter set token null] --> U[slice sesion]
style E fill:#a6e3a1,color:#11111b
style T fill:#f38ba8,color:#11111b

El refactor y sus límites

Hay que decir también que el refactor no siempre se hace entero ni conviene hacerlo de golpe. Un slice de setters que funciona y que nadie toca no es una emergencia; el criterio de prioridad es el mismo que para cualquier deuda, y aquí se mide por dos señales: cuánta lógica de dominio ha emigrado a los componentes que lo despachan, y con qué frecuencia hay que modificarlo. Un slice estable y con un solo consumidor puede vivir así indefinidamente. Uno que se toca cada semana y cuya secuencia de despachos está copiada en cuatro pantallas es exactamente donde el refactor se paga solo.

El procedimiento para deshacer un slice de setters empieza por un ejercicio que parece de redacción y es de análisis. Abre las DevTools, usa la aplicación como un usuario durante dos minutos y lee la lista de acciones resultante como si fuera una crónica. Si no puedes reconstruir lo que hiciste a partir de esa lista, tienes el diagnóstico. A continuación, para cada grupo de setters que se despachan juntos, busca el nombre del hecho que los provoca, escríbelo en pasado y conviértelo en una sola acción cuyo reducer haga todas las escrituras. La regla práctica es que si dos despachos aparecen siempre consecutivos en la misma secuencia, no son dos acciones: son una sola con dos consecuencias.

const checkoutSlice = createSlice({
  name: 'checkout',
  initialState: { paso: 'datos', pagando: false, error: null, pedidoId: null },
  reducers: {
    // El evento nombra el hecho; el reducer decide toda la forma resultante.
    pagoIniciado(e) {
      e.pagando = true
      e.error = null
    },
    pagoConfirmado(e, a: PayloadAction<{ pedidoId: string }>) {
      e.pagando = false
      e.paso = 'confirmacion'
      e.pedidoId = a.payload.pedidoId
    },
    pagoRechazado(e, a: PayloadAction<{ motivo: string }>) {
      e.pagando = false
      e.error = a.payload.motivo
    },
  },
})

Hay un beneficio colateral de este refactor que rara vez se menciona y que a menudo es el que convence a quien decide las prioridades: el catálogo de acciones se convierte en una descripción del producto legible por alguien que no programa. Una lista formada por sesionIniciada, pagoRechazado, pedidoCancelado y limiteDeCuotaAlcanzado puede revisarse con la persona responsable del negocio, que reconocerá los casos que faltan y señalará los que no existen en el dominio real. Una lista de asignaciones a campos no admite esa conversación con nadie. En proyectos donde hay que instrumentar analítica, cumplir requisitos de auditoría o construir un histórico de actividad, ese catálogo deja de ser documentación y pasa a ser la especificación de lo que hay que registrar.

Queda por delimitar el exceso contrario, porque existe y produce código peor que el problema original. Hay estado que genuinamente no tiene dominio, y forzarle una narrativa es teatro. La posición de un panel lateral, el modo claro u oscuro, el ancho de una columna redimensionable o el valor de un campo de texto mientras se escribe son datos de interfaz sin semántica de negocio, y bautizar su cambio como preferenciaDeAnchoDeColumnaAjustadaPorElUsuario no añade información: añade sílabas. Para esos casos, un reducer de escritura directa es la respuesta honesta, y la señal de que lo es resulta ser la misma que usamos en la lección anterior de este nivel: si el dato no debería estar en el store global, el problema no era el nombre de su setter.

La granularidad y el reparto

Recuperado el vocabulario del dominio, queda decidir cuántas acciones hacen falta, y aquí el criterio no es estético sino observacional. Una acción por hecho distinguible, entendiendo por hecho cada cosa que un usuario, un temporizador o el servidor pueden provocar y que tú querrías ver por separado en el historial. Ni una por campo, que es el error de partida, ni una por flujo entero, que es el exceso contrario y produce acciones tan gruesas que su carga útil se convierte en el estado completo y su reducer en una asignación disfrazada. Si al leer el registro no puedes distinguir dos situaciones que el negocio distingue, te falta granularidad; si tienes tres acciones que jamás aparecen separadas, te sobra.

El reparto entre slices es la prueba de fuego de que el refactor está bien hecho, porque solo funciona con eventos. Un slice declara sus propios hechos en sus reducers y escucha los ajenos en extraReducers, sin que el emisor sepa quién le escucha ni tenga que enterarse cuando aparezca un oyente nuevo. Esa asimetría —el emisor no conoce a sus consumidores— es lo que permite añadir una funcionalidad completa sin tocar el código que la dispara, y es imposible de conseguir con setters porque un setter nombra a su destinatario en el propio nombre.

// El emisor no sabe quien escucha; los oyentes se suman sin tocarlo.
const carritoSlice = createSlice({
  name: 'carrito',
  initialState,
  reducers: {},
  extraReducers: (b) => {
    b.addCase(sesionCerrada, () => initialState)
    b.addCase(organizacionCambiada, () => initialState)
  },
})

Una advertencia final sobre el nombrado, porque es donde el refactor se degrada con más facilidad. La convención de prefijar con el dominio y describir el hecho en pasado no sirve para que el código se lea bonito: sirve para que el registro de acciones se pueda agrupar, filtrar y analizar por origen. Un catálogo donde conviven usuario/sesionIniciada y setUser no tiene dos estilos, tiene dos modelos mentales conviviendo en el mismo historial, y quien lo lea dentro de un año tendrá que averiguar cuál de los dos estaba vigente en cada archivo.