Instantáneas: el historial como dos pilas de estados completos

Deshacer es, junto con guardar, la función que más confianza produce en una interfaz: mientras exista, el usuario explora sin miedo, porque ningún error es definitivo. Y sin embargo casi nunca se diseña, se improvisa cuando ya hay veinte pantallas construidas y alguien pregunta si se puede añadir. El resultado suele ser un parche frágil que deshace unas cosas y otras no. Este nivel entero trata de evitar esa deriva empezando por el principio, y el principio es el enfoque más tosco que existe: guardar el estado completo antes de cada cambio y volver a él cuando haga falta. Lo llamamos instantáneas, y su virtud es que no puede desincronizarse, porque no reconstruye nada: reinstala un valor que ya fue verdad. Lo interesante es que esa ingenuidad esconde una estructura elegante —un zipper sobre el tiempo— y que su fama de derrochador es en buena medida un malentendido heredado de la época en que el estado se clonaba a mano. Si el estado es inmutable y las actualizaciones comparten estructura, la instantánea es mucho más barata de lo que su nombre sugiere. Esta lección construye el historial completo, enuncia sus invariantes y sitúa con precisión la frontera a partir de la cual hay que buscar algo mejor.

El zipper del tiempo: pasado, presente y futuro

Un historial no es una lista de estados: es una lista con un dedo apoyado en un punto. Esa distinción tiene nombre en programación funcional —el zipper de Huet— y consiste en representar el foco dentro de una secuencia partiéndola en tres: lo que queda a un lado, el elemento enfocado y lo que queda al otro. Aplicado al tiempo, el foco es el presente, lo que queda detrás es el pasado en orden inverso y lo que queda delante es el futuro al que podrías rehacer. La ventaja de esta representación frente a guardar un array y un índice es que las dos operaciones que más importan, deshacer y rehacer, se vuelven desplazamientos de coste constante entre las puntas de dos pilas, sin recorrer ni copiar nada.

type Historial<T> = {
  pasado: T[]     // estados anteriores, el mas reciente al final
  presente: T     // el estado visible ahora mismo
  futuro: T[]     // estados deshechos, el mas proximo al final
}

const nuevo = <T,>(inicial: T): Historial<T> => ({
  pasado: [],
  presente: inicial,
  futuro: [],
})

Conviene detenerse en el orden elegido para las dos pilas, porque es lo que hace que todo lo demás sea trivial. Tanto pasado como futuro se apilan por el final, de modo que el vecino temporal del presente está siempre en la última posición de ambos arrays. Deshacer consiste en mover el presente al futuro y traer el último elemento del pasado; rehacer es la operación simétrica. No hay índices que mantener sincronizados ni desplazamientos que recalcular: la estructura codifica la posición.

flowchart LR
P0[pasado n-2] --> P1[pasado n-1]
P1 -->|deshacer| PR[PRESENTE]
PR -->|rehacer| F1[futuro 1]
F1 --> F2[futuro 2]
style PR fill:#cba6f7,color:#11111b

Las tres operaciones y el invariante de la rama muerta

Registrar un cambio empuja el presente al pasado y coloca el estado nuevo como presente. Deshacer y rehacer trasvasan un elemento entre pilas. Las tres son puras y devuelven un historial nuevo, lo que las hace triviales de testear y de integrar en cualquier store inmutable.

function registrar<T>(h: Historial<T>, siguiente: T): Historial<T> {
  if (Object.is(siguiente, h.presente)) return h  // nada cambio, no ensucies
  return { pasado: [...h.pasado, h.presente], presente: siguiente, futuro: [] }
}

function deshacer<T>(h: Historial<T>): Historial<T> {
  if (h.pasado.length === 0) return h
  const anterior = h.pasado[h.pasado.length - 1]
  return {
    pasado: h.pasado.slice(0, -1),
    presente: anterior,
    futuro: [...h.futuro, h.presente],
  }
}

function rehacer<T>(h: Historial<T>): Historial<T> {
  if (h.futuro.length === 0) return h
  const siguiente = h.futuro[h.futuro.length - 1]
  return {
    pasado: [...h.pasado, h.presente],
    presente: siguiente,
    futuro: h.futuro.slice(0, -1),
  }
}

La línea que decide el carácter del sistema es la que vacía futuro dentro de registrar. Ese vaciado codifica una decisión de diseño con consecuencias visibles: si el usuario deshace tres pasos y a continuación escribe algo nuevo, la rama que había deshecho se pierde para siempre. Es el comportamiento canónico en prácticamente todo el software de consumo, y su justificación es cognitiva antes que técnica: mantener viva una rama invisible obligaría al usuario a razonar sobre un árbol que no ve. La alternativa existe y es respetable —conservar la bifurcación y ofrecer un árbol de deshacer navegable, como hace Vim con su undo tree— pero cambia el modelo mental de una línea a un grafo, y esa carga solo se paga en herramientas para profesionales que la piden.

El coste real: compartir no es clonar

La objeción inmediata a las instantáneas es la memoria, y suele enunciarse mal. La frase habitual —guardar el estado completo en cada paso es inviable— asume que cada entrada del historial ocupa el tamaño del estado. Eso solo es cierto si copias en profundidad. Con actualizaciones inmutables reales, el estado nuevo comparte con el anterior todas las ramas que no cambiaron, de modo que apilar el presente no copia nada: apila una referencia a un árbol que ya existe, y el consumo adicional de un paso es proporcional al camino modificado, no al tamaño total. Cincuenta instantáneas de un árbol de diez mil nodos donde cada paso toca una hoja no cuestan quinientos mil nodos, sino diez mil más unos pocos cientos.

// Con actualizacion inmutable: el paso cuesta el camino, no el arbol
const siguiente = { ...estado, doc: { ...estado.doc, titulo: "otro" } }
siguiente.ajustes === estado.ajustes   // true  -> rama compartida, coste cero
siguiente.doc      === estado.doc      // false -> unico nodo realmente nuevo

// Con clon profundo: el paso cuesta el arbol entero, cada vez
const copiaCara = structuredClone(estado)  // O de n en tiempo Y en memoria

Esto reordena por completo el juicio sobre el enfoque. El enemigo no es la instantánea, es el clon. Y aun así el consumo crece de forma monótona, porque el historial retiene versiones que nadie volverá a mirar e impide que el recolector de basura libere las ramas viejas. De ahí la única disciplina imprescindible: acotar. Un historial en producción se limita a una profundidad fija —entre veinte y cien pasos cubre el noventa y nueve por ciento de los deshacer reales— descartando por la cabeza de la pila, lo que convierte el consumo en constante y elimina la clase entera de incidencias por crecimiento sin techo.

const LIMITE = 50

function acotar<T>(h: Historial<T>): Historial<T> {
  return h.pasado.length <= LIMITE
    ? h
    : { ...h, pasado: h.pasado.slice(h.pasado.length - LIMITE) }
}

Conectar el historial al store

Queda una decisión de arquitectura que se toma mal con frecuencia: qué porción del estado entra en el historial. La tentación es envolver el store entero, y es un error, porque arrastra al pasado cosas que no deben viajar —la sesión del usuario, la caché del servidor, los datos de conexión, el estado efímero de la interfaz—. El historial debe envolver únicamente el documento versionable, y el resto del estado debe vivir fuera de él, inmune a los saltos temporales. Separar ambas mitades desde el primer día evita una refactorización dolorosa más adelante y hace que el deshacer no tenga efectos secundarios sorprendentes.

type App = {
  historial: Historial<Doc>   // SOLO el documento entra aqui
  sesion: Sesion              // fuera del historial: no debe viajar
  cacheServidor: Cache        // fuera: la gestiona su propia capa
}

const puedeDeshacer = (a: App) => a.historial.pasado.length > 0
const puedeRehacer  = (a: App) => a.historial.futuro.length > 0
const docActual     = (a: App) => a.historial.presente

Con esa separación hecha, exponer la funcionalidad es trivial y conviene hacerlo de forma completa desde el principio: los dos predicados anteriores alimentan el estado deshabilitado de los botones, el atajo de teclado se conecta a las mismas funciones puras y la interfaz nunca lee el historial directamente sino a través del selector docActual. Ese último punto importa más de lo que parece, porque mantiene a todos los componentes ignorantes de que existe un historial: para ellos solo hay un documento, y el día que se cambie el enfoque de instantáneas a parches ninguno tendrá que enterarse.