Actions y action creators

Si el reducer es el verbo de Redux, la acción es el sustantivo. Una acción es la unidad mínima de información que entra en el sistema: un objeto plano y serializable que declara que algo sucedió. Y aquí se esconde la decisión de diseño más sutil y más ignorada de todo Redux: una acción no es una orden que le das al estado, es una noticia que le cuentas. La diferencia entre “haz esto” y “esto ocurrió” parece retórica, pero determina si tu store será un conjunto legible de eventos o una pila de setters disfrazados. Quien confunde acción con comando escribe Redux sintácticamente correcto y arquitectónicamente muerto.

Un objeto plano con un type

Una acción es, literalmente, un objeto JavaScript corriente. Su único requisito absoluto es un campo type, y por convención ese type es una cadena de texto legible que nombra el evento en formato dominio/evento. Todo lo demás —los datos que acompañan al evento— vive en el resto de campos. No hay clases, no hay herencia, no hay métodos: la austeridad es el punto.

// La accion minima: solo un type.
{ type: 'contador/reiniciado' }

// Una accion con datos: el payload transporta lo que el reducer necesitara.
{ type: 'todos/todoAgregado', payload: { id: 't1', texto: 'leer a Elm' } }

Que sea un objeto plano y serializable no es un capricho estético: es la condición que habilita todo lo demás. Como una acción es JSON puro, se puede registrar en un log, guardar en disco, enviar por la red a otra pestaña o a un servidor, y volver a reproducir más tarde. El type serializable es la clave de bóveda del time-travel: rebobinar el estado es volver a aplicar la misma lista de acciones, y eso solo es posible porque cada acción es un dato inerte y no una llamada a función irrepetible.

Eventos, no órdenes

Aquí está el corazón filosófico de la lección. La tentación del principiante es tratar las acciones como setters: SET_USUARIO, SET_CARGANDO, ACTUALIZAR_TOTAL. Cada una dice al estado qué hacer y con qué valor. Funciona, y es un error de diseño. La forma correcta es que la acción describa qué pasó en el mundo —sesion/inicioSesion, checkout/pagoConfirmado— y deje que cada reducer decida cómo reaccionar. La metáfora oficial de la documentación de Redux es exacta: piensa en una acción como el titular de un periódico que narra un suceso, no como una instrucción que ejecutas.

La consecuencia práctica de esta distinción es enorme y no se ve hasta que la app crece. Si modelas comandos, cada trozo de estado que deba cambiar ante un mismo suceso necesita su propio comando, y la vista se convierte en la orquestadora que sabe demasiado: tiene que despachar SET_CARRITO_VACIO, SET_TOTAL_CERO y SET_CUPON_NULO una tras otra. Si modelas eventos, la vista despacha un solo checkout/pedidoCompletado y cada reducer interesado —el del carrito, el del total, el del cupón— reacciona por su cuenta. Un evento, muchos oyentes; esa es la desnormalización del control que hace escalable a Redux.

flowchart LR
E[suceso del mundo] --> A[una accion evento]
A --> R1[reducer carrito]
A --> R2[reducer total]
A --> R3[reducer historial]
style A fill:#f9e2af,color:#11111b
style R1 fill:#89b4fa,color:#11111b
style R2 fill:#89b4fa,color:#11111b
style R3 fill:#89b4fa,color:#11111b

Anatomía: Flux Standard Action

Como el objeto acción es libre, la comunidad estandarizó su forma para que las herramientas y el middleware puedan trabajar sin adivinar. La convención se llama Flux Standard Action y define cuatro campos con significado fijo: type obligatorio, payload con los datos, error como bandera booleana cuando la acción representa un fallo, y meta para información que no es ni el resultado ni el error —un identificador de petición, una marca de tiempo—.

Seguir esta forma no es burocracia: es lo que permite que un middleware genérico distinga una acción de error de una normal sin conocer tu dominio, o que las DevTools sepan dónde está el payload para mostrarlo. La estandarización de la forma es lo que convierte un ecosistema de piezas sueltas en herramientas que encajan.

Action creators: fábricas de intención

Escribir el objeto acción a mano en cada punto de despacho es frágil: un type mal tecleado no falla, simplemente no hace nada, y ese es de los bugs más silenciosos que existen. Un action creator es sencillamente una función que devuelve la acción ya formada; centraliza la estructura en un solo lugar, para que el resto del código exprese intención y no ensamble objetos.

// A mano, fragil: un typo en el type falla en silencio.
dispatch({ type: 'todos/todoAgregado', payload: { id, texto } })

// Con action creator: la forma vive en un solo sitio.
const todoAgregado = (id: string, texto: string) => ({
  type: 'todos/todoAgregado' as const,
  payload: { id, texto },
})

dispatch(todoAgregado('t1', 'leer a Elm'))