Time travel: qué significa realmente viajar por el historial

La demostración que vendió Redux a una generación entera dura quince segundos: alguien arrastra un deslizador hacia atrás y la interfaz retrocede sola, estado por estado, como si el tiempo obedeciera. La palabra elegida para nombrarlo —viaje en el tiempo— es a la vez brillante y tramposa, porque sugiere que el programa vuelve atrás cuando en realidad nada vuelve atrás nunca. Entender qué ocurre de verdad bajo esa animación es lo que separa a quien usa la función de quien sabe cuándo puede confiar en ella. Y la respuesta es prosaica y hermosa: no hay viaje, hay recálculo. Todo el resto de esta lección son las consecuencias de esa frase.

No hay viaje, hay recálculo

La afirmación central es simple: las DevTools no guardan una máquina del tiempo, guardan una lista. Tienen el estado inicial de la aplicación y la secuencia ordenada de todas las acciones despachadas desde entonces. Para mostrarte el mundo tal como estaba en el instante número siete, no rebobinan nada: toman el estado inicial y vuelven a aplicar el reducer sobre las siete primeras acciones, exactamente igual que la primera vez. El resultado es idéntico porque el reducer es puro, y es idéntico siempre, tantas veces como quieras repetirlo.

Las implementaciones reales optimizan ese pliegue guardando fotografías intermedias para no recalcular desde cero en cada movimiento del deslizador, pero la optimización no cambia el modelo: sigue siendo válido pensar que cada estado se obtiene aplicando el reducer a un prefijo del historial, y esa es la imagen mental que hay que retener.

Dicho de otro modo, el estado en cualquier punto del historial no es un dato que se recuperó: es un valor que se recalculó a demanda mediante un pliegue de la lista de acciones. Esta es la razón profunda por la que la pureza del reducer no era una manía académica. Si el reducer consultase la hora, generara un identificador aleatorio o llamara a la red, replegarlo daría un resultado distinto cada vez y la vista del pasado sería una ficción diferente en cada intento.

// El estado de cualquier instante es un pliegue del historial. Sin magia.
function estadoEn(indice: number): Estado {
  return historial
    .slice(0, indice)
    .reduce((acc, accion) => reducer(acc, accion), estadoInicial)
}

Basta una impureza mínima para que la reconstrucción deje de ser fiel, y el ejemplo canónico cabe en dos líneas:

// Rompe el pliegue: el mismo historial da un resultado distinto cada vez.
function reducer(state: Estado, accion: Accion): Estado {
  if (accion.type === 'nota/crear') {
    return { ...state, ultima: { id: crypto.randomUUID(), en: Date.now() } }
  }
  return state
}

Al replegar mañana ese historial obtendrás otro identificador y otra marca temporal, así que el pasado que la extensión te enseña no es el pasado que ocurrió sino una versión nueva de él. La lección tercera de este nivel dedica una sección entera a mover esas dos impurezas al borde, porque son las mismas que rompen la reproducción de sesiones. Conviene retener ya la forma general: cada valor que el reducer inventa en lugar de recibir es un punto por donde el historial pierde fidelidad.

Que la interfaz siga al estado sin resistirse es la otra mitad del truco, y también estaba pagada de antemano. Una vista de React es una función del estado: dale el estado del instante siete y dibujará la pantalla del instante siete, sin saber ni preguntar si ese estado es el actual o uno reconstruido. La combinación de un reducer puro y una vista pura convierte al historial en la única fuente de verdad y al presente en un caso particular del pasado: el último.

Esa última frase no es un adorno retórico y conviene tomársela literalmente, porque explica por qué el mecanismo no necesita ningún modo especial. La aplicación no distingue entre estar viva y estar siendo inspeccionada: en ambos casos recibe un estado y dibuja. Cuando arrastras el deslizador no entras en un modo de depuración con reglas propias, simplemente le entregas a la misma función de vista un argumento distinto del que le habría tocado. Por eso los componentes no necesitan saber nada de todo esto, y por eso la funcionalidad no se degrada a medida que la aplicación crece: no hay maquinaria adicional que mantener sincronizada.

Desactivar acciones: el experimento contrafactual

La segunda capacidad, menos vistosa y mucho más útil, es poder desactivar una acción concreta en mitad del historial y ver qué mundo resulta sin ella. El mecanismo es el mismo pliegue, con la lista filtrada: se recorre el historial saltándose la acción marcada y se recalcula todo lo posterior. Lo que obtienes es un experimento contrafactual sobre tu propia sesión, algo que en la mayoría de las arquitecturas exigiría reproducir la situación a mano.

Es importante ver que esta capacidad es estrictamente más fuerte que la anterior. Saltar a un instante te enseña un pasado que efectivamente ocurrió; desactivar una acción te enseña un pasado que no ocurrió nunca, un mundo alternativo calculado a partir del mismo reducer. Que un depurador pueda mostrarte con fidelidad algo que no pasó es una consecuencia nada obvia de haber hecho el estado recomputable, y no hay ninguna herramienta equivalente para código que muta.

flowchart TD
I[estado inicial] --> A1[accion 1]
A1 --> A2[accion 2]
A2 --> A3[accion 3 desactivada]
A3 --> A4[accion 4]
A4 --> R[estado recalculado sin la 3]
I -.mismo reducer.-> R
style A3 fill:#f38ba8,color:#11111b
style R fill:#a6e3a1,color:#11111b

El valor diagnóstico es directo. Si sospechas que cierta acción es la culpable de un estado corrupto, la desactivas: si el bug desaparece, tu hipótesis se confirma sin escribir una línea de código; si persiste, has eliminado un sospechoso y puedes seguir. Es bisección aplicada al historial, y su coste por experimento es un clic, frente a los minutos que costaría reproducir la misma pregunta comentando código y recargando.

La cautela adicional es que desactivar solo tiene sentido con acciones independientes. Si la acción que quitas era la que creaba la entidad sobre la que operan las siguientes, el pliegue resultante no es un mundo alternativo coherente sino uno imposible, y las conclusiones que saques de él no valen. Antes de interpretar el resultado, comprueba que las acciones posteriores siguen teniendo sentido sin la que eliminaste. La única cautela es recordar que la respuesta que obtienes es sobre el estado, no sobre el mundo: si aquella acción había disparado también una escritura remota, desactivarla en las DevTools no deshace la escritura, solo el efecto que tuvo sobre tu árbol local.

La tercera tarjeta merece una nota aparte porque es la que más productividad aporta y la que menos se usa. Con el historial fijo, editar el reducer y guardar hace que las DevTools vuelvan a plegar exactamente las mismas acciones sobre el código nuevo. Tienes así un bucle de prueba y corrección donde la entrada permanece constante y solo cambia la función bajo estudio, que es la condición ideal de cualquier experimento y algo muy difícil de conseguir a mano.

La cuarta tarjeta, fijar el punto de partida, cumple una función distinta y complementaria: descarta el historial anterior y declara el estado actual como nuevo origen. Es la operación menos vistosa de las cuatro y la que más se agradece en una investigación larga. Sirve para acotar sesiones largas —llegas hasta el punto donde empieza lo interesante, fijas, y a partir de ahí trabajas con un historial corto y legible— y también para no arrastrar durante horas el arranque de la aplicación en cada pliegue. Es la operación que convierte una sesión de trabajo real en un experimento manejable.

El límite: los efectos ya ocurrieron

Aquí termina la magia y empieza la honestidad. El pliegue recalcula estado; no cancela nada de lo que salió de tu proceso. Si en el instante cinco tu aplicación envió una petición que borró un registro en la base de datos, retroceder al instante cuatro devuelve tu árbol local a como estaba, y el registro sigue borrado. Lo mismo vale para el correo enviado, el pago cursado, la analítica registrada, la entrada escrita en localStorage o el mensaje emitido por un socket.

La frontera es exacta y vale la pena enunciarla con precisión: vuelve atrás todo lo que es función pura del historial, y no vuelve nada de lo que fue observado por el exterior. Esa frontera coincide punto por punto con la que separaba reducers de middleware en el Nivel 4. Los efectos viven en el middleware precisamente porque no son replegables, y el time travel funciona sobre los reducers precisamente porque sí lo son. La arquitectura no tiene aquí una limitación accidental; tiene una consecuencia deducible de su propio diseño.

Esa frontera, además, es una herramienta de diseño y no solo una advertencia. Cuando dudes de dónde colocar una pieza de lógica, pregúntate si querrías que volviera atrás con el deslizador. Si la respuesta es sí, esa lógica pertenece al reducer y debe ser pura; si es no, pertenece al borde y su sitio es el middleware. Es el mismo criterio del Nivel 4 formulado desde el otro lado, y tiene la ventaja de ser una pregunta concreta y contestable en lugar de una discusión abstracta sobre pureza.

Existe también un límite de recursos que se olvida por lo obvio. El historial completo se guarda en memoria, y en una sesión larga con acciones frecuentes crece hasta hacer lenta la propia extensión. Las DevTools limitan por defecto el número de acciones retenidas y permiten ajustarlo, además de filtrar por tipo para excluir el ruido de alta frecuencia. Un historial acotado y legible vale más que uno completo e inmanejable. La última lección de este nivel vuelve sobre este coste con números y añade la razón menos técnica y más seria para no retenerlo todo.

Conviene además distinguir dos clases de irreversibilidad que se confunden. Hay efectos que salieron y no vuelven porque otro sistema los observó —el correo, el pago, la escritura remota— y hay estado que no vuelve porque nunca estuvo en el historial: un valor guardado en una variable de módulo, un contador dentro de una clase, una referencia mutable escondida en un hook. El primer caso es una limitación honesta del modelo y se acepta. El segundo es un defecto que se puede corregir, y el deslizador es justo el instrumento que lo delata: si al retroceder la interfaz no vuelve del todo a su estado anterior, hay estado viviendo fuera del store y acabas de encontrar exactamente dónde.

El mismo teorema fuera del navegador

Merece la pena sacar esta idea del contexto de una extensión de Chrome, porque la estructura que la sostiene es mucho más vieja y mucho más general que Redux. Cuando decides que la verdad de un sistema no es su estado actual sino la secuencia de hechos que lo produjeron, y que el estado se obtiene plegando esa secuencia, has adoptado el patrón que en el mundo de los sistemas de información se llama registro de eventos. Redux es una implementación diminuta de esa idea aplicada a la interfaz de usuario, y el time travel es la propiedad que cualquier sistema con esa forma obtiene gratis.

Verlo así reordena la genealogía de la herramienta. Redux no inventó nada en este terreno: tomó una estructura conocida desde hacía décadas en contabilidad, en bases de datos y en control de versiones, y la aplicó a un dominio donde nadie la había aplicado, el de la interfaz de un navegador. Su aportación real fue de traducción y de divulgación, no de invención, y eso explica que el modelo haya sobrevivido a la librería concreta que lo popularizó.

Reconocer esa familia tiene un valor práctico inmediato, porque te da el vocabulario para saber qué esperar de cada diseño antes de construirlo. Si el estado de un módulo es un pliegue determinista de sus entradas, tendrás reconstrucción del pasado, reproducción y verificación sobre entrada fija; si no lo es, no las tendrás por mucho que instales herramientas. Y a la inversa: cuando alguien te pida en un producto una funcionalidad de auditoría, de deshacer o de replicar la sesión de un usuario, lo que en realidad está pidiendo es que el módulo tenga esta forma, y decidirlo al principio cuesta una tarde mientras que introducirlo después cuesta un rediseño.

La comparación también marca las diferencias, y conviene no exagerar el parentesco. Un registro de eventos de servidor es duradero, ordenado globalmente y pensado para sobrevivir décadas; el historial de Redux vive en memoria, muere al recargar la pestaña y solo ordena lo que ocurrió en un cliente. Redux no es un sistema de eventos, es un sistema con la forma de uno, y esa forma le basta para obtener en el ámbito reducido de una interfaz las mismas tres propiedades: reconstrucción, auditoría y reproducción. Saber que la analogía es de estructura y no de escala evita tanto despreciarla como pedirle garantías que nunca ofreció.