Comandos: guardar la operación y su inversa

La lección anterior terminó con tres síntomas que anuncian el final de las instantáneas: nodos grandes que no se pueden compartir, cambios continuos y demasiado frecuentes, y un historial que además tiene que viajar. Los tres apuntan al mismo desperdicio. Cuando el usuario mueve un rectángulo dos píxeles dentro de un documento con diez mil formas, guardar el documento entero para poder retroceder esos dos píxeles es una desproporción difícil de defender. Lo que cambió cabe en una frase: la forma con identificador siete se desplazó de una posición a otra. Y si eso cabe en una frase, el historial también. El patrón comando lleva esa observación hasta el final: no se guarda lo que el estado era, se guarda lo que se hizo, junto con la receta exacta para desandarlo. El resultado es un historial ligero, transmisible y semánticamente rico, capaz de decirte no solo que algo cambió sino qué significó ese cambio. El precio es exigente y esta lección no lo esconde: por cada operación que añadas al producto tendrás que escribir y sostener su inversa, y una inversa incorrecta no falla al escribirla sino tres deshacer más tarde, cuando ya nadie recuerda el commit que la introdujo.

El comando como par de funciones

Un comando es un valor que representa una intención junto con la manera de aplicarla y la manera de revertirla. La formulación mínima en TypeScript son dos funciones del estado en el estado, y la propiedad que las liga es la que define todo el sistema: revertir después de aplicar debe devolver exactamente el estado de partida. Es la ley de ida y vuelta, y no es una recomendación sino la condición de existencia del historial. Si falla para un solo comando, el historial deja de ser un registro del pasado y se convierte en una fuente de estados que nunca ocurrieron.

type Comando<S> = {
  nombre: string             // etiqueta semantica, util en la UI y en logs
  aplicar: (s: S) => S
  revertir: (s: S) => S
}

// Ley de ida y vuelta que todo comando debe cumplir:
//   revertir(aplicar(s)) equivale a s, para todo s valido

Esa ley tiene una lectura algebraica que conviene tener presente porque explica por qué el enfoque funciona. El conjunto de operaciones sobre el estado, con la composición como ley interna y la operación neutra como elemento identidad, forma un monoide; exigir que toda operación tenga inversa lo convierte en un grupo. Deshacer no es entonces un truco de interfaz sino la aplicación del elemento inverso, y rehacer la reaplicación del elemento original. La consecuencia práctica es inmediata: si una de tus operaciones no tiene inversa dentro de tu modelo, el conjunto no es un grupo y ninguna cantidad de código de interfaz va a arreglarlo. Hay que cambiar el modelo.

El historial pasa entonces a ser una pila de comandos con un puntero, en lugar de una pila de estados. La estructura es la misma que la del zipper de la lección anterior, pero lo que se apila pesa lo que pesa la operación.

type Registro<S> = { hechos: Comando<S>[]; deshechos: Comando<S>[] }

function ejecutar<S>(s: S, r: Registro<S>, c: Comando<S>): [S, Registro<S>] {
  return [c.aplicar(s), { hechos: [...r.hechos, c], deshechos: [] }]
}

function deshacer<S>(s: S, r: Registro<S>): [S, Registro<S>] {
  const c = r.hechos.at(-1)
  if (!c) return [s, r]
  return [c.revertir(s), { hechos: r.hechos.slice(0, -1), deshechos: [...r.deshechos, c] }]
}

Inversas correctas: la información que se destruye

Aquí está la dificultad genuina del patrón, y no es la que se anticipa. Aplicar comandos es fácil; invertirlos solo es fácil cuando la operación es simétrica. Mover una forma de una posición a otra es trivialmente reversible porque no se pierde nada: la inversa es el mismo movimiento con los extremos intercambiados. Borrar un elemento de una lista no lo es en absoluto, porque la operación destruye información —el contenido borrado y su posición— y esa información no está en el estado resultante. La única forma de recuperarla es capturarla en el instante en que aún existe. Por eso los comandos reales no son funciones puras aisladas sino cierres que memorizan su contexto de ejecución.

type Doc = { items: string[] }

// Correcto: el comando se construye capturando lo que va a destruir
function borrarItem(indice: number, borrado: string): Comando<Doc> {
  return {
    nombre: "borrar-item",
    aplicar: (d) => ({ ...d, items: d.items.filter((_, i) => i !== indice) }),
    revertir: (d) => ({
      ...d,
      items: [...d.items.slice(0, indice), borrado, ...d.items.slice(indice)],
    }),
  }
}

// Incorrecto y silencioso: sin el valor borrado, la inversa inventa un hueco
//   revertir: (d) => ({ ...d, items: [...d.items.slice(0, indice), "", ...] })

La regla general que se extrae de esto es que un comando debe construirse en el momento de la acción, no en el momento del deshacer, y debe llevar consigo todo lo que la operación vaya a hacer irrecuperable. Cuando la información destruida es voluminosa —el contenido de una tabla que se vacía, una selección de mil nodos que se elimina— el comando engorda hasta parecerse a una instantánea parcial, y eso es correcto y esperable: el enfoque no promete comandos pequeños, promete comandos proporcionales al cambio. Un cambio grande produce un comando grande, y ahí ya no hay ahorro que buscar.

Transacciones y el coste de mantenimiento

Una acción del usuario rara vez corresponde a un único comando. Agrupar varias formas alinea cinco elementos, pegar un fragmento inserta un nodo y actualiza tres índices. Para que el deshacer respete la unidad perceptual de la acción —el asunto que ocupa por completo la lección cuatro de este nivel— los comandos se componen en uno solo. La composición es la operación natural del monoide, y su única sutileza es el orden: al revertir, los subcomandos se recorren en orden inverso, porque cada uno se escribió asumiendo el estado que dejó el anterior.

function transaccion<S>(nombre: string, cs: Comando<S>[]): Comando<S> {
  return {
    nombre,
    aplicar: (s) => cs.reduce((acc, c) => c.aplicar(acc), s),
    // LIFO estricto: el ultimo aplicado es el primero revertido
    revertir: (s) => [...cs].reverse().reduce((acc, c) => c.revertir(acc), s),
  }
}

Con la composición resuelta, el enfoque queda completo y es objetivamente superior a las instantáneas en coste, en expresividad y en transmisibilidad: un historial de comandos se puede enviar por la red, registrar en un log de auditoría, mostrar como una lista legible de acciones y reproducir en otro cliente. Y aun así muchos equipos lo abandonan, por una razón que no aparece en los tutoriales y que conviene enunciar sin adornos.

Ese desfase entre causa y síntoma es lo que hace peligroso al patrón. Una inversa incorrecta no lanza ninguna excepción: produce un estado plausible pero falso, que el usuario acepta sin darse cuenta y sobre el que sigue trabajando. La corrupción se acumula en silencio. El único antídoto proporcionado al riesgo son las pruebas basadas en propiedades: en lugar de comprobar casos concretos, se genera aleatoriamente una secuencia larga de comandos válidos y se verifica que aplicarlos todos y revertirlos todos devuelve el estado inicial. Esa única prueba cubre el espacio entero de combinaciones, incluidas las que nadie pensó.

El log de comandos vale más que el deshacer

Hay una consecuencia del patrón que suele descubrirse tarde y que por sí sola justifica adoptarlo. Al guardar operaciones en lugar de estados, el historial deja de ser una estructura interna y se convierte en un artefacto con valor propio: una descripción ordenada, legible y compacta de todo lo que ocurrió. Esa lista es simultáneamente el motor del deshacer, el registro de auditoría, el formato de sincronización entre dispositivos y el caso de prueba que reproduce un fallo. Cuatro necesidades que en otras arquitecturas se resuelven con cuatro mecanismos distintos, aquí las cubre el mismo dato.

flowchart LR
A[accion del usuario] --> C[comando con inversa]
C --> E[aplicar sobre el estado]
C --> L[log de comandos]
L --> D[deshacer y rehacer]
L --> S[sincronizar con otros clientes]
L --> AU[auditoria y trazabilidad]
L --> RP[reproducir un fallo en local]
style L fill:#cba6f7,color:#11111b

Esta es también la puerta de entrada al event sourcing, donde el log deja de ser un acompañante del estado y pasa a ser la única fuente de verdad: el estado actual no se guarda, se calcula plegando el log desde el principio. Llevado hasta ahí, el patrón cambia de escala y arrastra sus propios problemas —el pliegue completo se vuelve caro y hay que introducir instantáneas periódicas como puntos de apoyo, la evolución del esquema obliga a versionar cada tipo de comando, y el log crece sin techo—. La observación interesante es que la solución a la lentitud del pliegue es precisamente el enfoque de la lección anterior: los dos extremos del espectro acaban necesitándose el uno al otro.

// Event sourcing en miniatura: el estado es un pliegue del log
const estadoActual = log.reduce((s, c) => c.aplicar(s), inicial)

// Y el punto de apoyo periodico que lo hace viable
type Checkpoint<S> = { indice: number; estado: S }
const desdeCheckpoint = <S,>(cp: Checkpoint<S>, log: Comando<S>[]) =>
  log.slice(cp.indice).reduce((s, c) => c.aplicar(s), cp.estado)