Rollback en fallo

Todo el edificio del optimismo descansa sobre una apuesta: que la mutación tendrá éxito. La mayoría de las veces gana, pero de vez en cuando el servidor rechaza la operación —falla la red, caduca la sesión, una regla de negocio dice que no— y en ese instante la predicción que pintaste se convierte en una mentira visible en la pantalla. El rollback es el acto de retirar esa mentira: devolver la interfaz al estado exacto que tenía antes de que te adelantaras. Y aquí surge la verdad incómoda de esta técnica: no puedes revertir a un pasado que no guardaste. El rollback no es un botón mágico de deshacer, sino la restauración de una fotografía que tuviste la precaución de tomar antes de mentir. Sin esa fotografía —el snapshot— el optimismo es un salto sin red; con ella, es un salto calculado del que siempre puedes volver.

El snapshot: guardar el pasado antes de mentir

La secuencia correcta invierte el instinto. Antes de aplicar la predicción, captura el estado actual y guárdalo aparte; ese valor es tu única vía de regreso. Solo después mutas de forma optimista. Si la petición falla, restauras el snapshot; si tiene éxito, lo descartas. La captura debe ocurrir en el mismo instante que la mutación, no antes ni después, porque el snapshot tiene que reflejar exactamente el estado sobre el que se aplicó la predicción.

async function alternarMeGusta() {
  const anterior = meGusta;      // snapshot: el pasado, guardado
  setMeGusta(!anterior);          // prediccion optimista aplicada

  try {
    await api.alternarMeGusta(postId);
  } catch {
    setMeGusta(anterior);         // rollback: restaura el snapshot
    mostrarError("No se pudo guardar");
  }
}

En un valor escalar como este, el snapshot es trivial. Pero cuando el estado optimista es una lista, un objeto anidado o una entrada de cache normalizada, el snapshot debe ser una copia fiel y completa de esa estructura antes de tocarla, porque restaurar solo una parte deja el resto viviendo en el futuro que nunca ocurrió.

// Snapshot de una estructura: una copia, nunca la misma referencia
const anterior = structuredClone(tareas); // fotografia independiente
setTareas((prev) =>
  prev.map((t) => (t.id === id ? { ...t, hecha: !t.hecha } : t)),
);
// ...si la peticion falla: setTareas(anterior);

Revertir de forma atómica y completa

Una reversión a medias es peor que no revertir: deja el estado en una mezcla incoherente de pasado y futuro fallido. Si tu mutación optimista tocó tres campos, el rollback debe restaurar los tres; si añadió un elemento y actualizó un contador, debe deshacer ambos. La regla es que el rollback restaure el snapshot entero de una vez, como una transacción que se aborta y vuelve al punto de guardado, no como una serie de correcciones campo a campo que podrían quedarse a mitad.

// Rollback atomico: un solo reemplazo, vuelve entero al pasado
onError(_error, _variables, ctx) {
  setEstado(ctx.snapshot);
}

// Anti-patron: deshacer a mano cada efecto, con riesgo de quedar a mitad
onError() {
  setContador((c) => c - 1);      // y si esto corre
  setLista((l) => l.slice(0, -1)); // pero esto lanza? estado corrupto
}

Restaurar el snapshot completo es, además, más simple de razonar: no necesitas recordar qué tocaste ni en qué orden deshacerlo, solo volver a la fotografía. El anti-patrón de deshacer efecto por efecto obliga a mantener sincronizada la lista de deshacer con la de hacer, y esa sincronización se rompe en cuanto alguien añade un cuarto efecto y olvida su reverso.

flowchart TD
S[capturar snapshot del estado] --> A[aplicar prediccion optimista]
A --> R[disparar peticion]
R --> OK[servidor confirma]
R --> ERR[servidor rechaza]
OK --> D[descartar snapshot]
ERR --> B[restaurar snapshot completo]
B --> N[avisar al usuario]
style ERR fill:#f38ba8,color:#11111b
style B fill:#fab387,color:#11111b
style OK fill:#a6e3a1,color:#11111b

Carreras: cuando el pasado se mueve bajo tus pies

Hay una sutileza que causa los bugs más difíciles del optimismo. Imagina que, en el momento de mutar, hay una revalidación en vuelo —una petición previa que aún no ha respondido— cuyo resultado va a escribirse en el mismo estado. Si tomas el snapshot ahora y esa revalidación responde después, sobrescribirá tu estado optimista con datos viejos, o peor, contaminará tu snapshot con un valor que no corresponde al pasado real. La consecuencia es un rollback que restaura un estado equivocado. La defensa es cancelar las peticiones en vuelo sobre ese dato antes de capturar el snapshot, de modo que ninguna respuesta rezagada pueda colarse entre tu predicción y tu reversión.

Escrito como código, ese orden canónico reúne las tres lecciones del nivel en una sola función: cancelar y capturar preparan el terreno, la predicción se aplica, y el desenlace bifurca entre rollback y reconciliación sin dejar ningún camino sin cubrir.

async function mutarSeguro(nuevo) {
  await cancelarEnVuelo(["dato"]); // 1. cancelar carreras
  const snapshot = leer(["dato"]);  // 2. capturar el pasado
  escribir(["dato"], nuevo);        // 3. prediccion optimista
  try {
    await api.guardar(nuevo);       // 4. disparar la peticion
  } catch {
    escribir(["dato"], snapshot);   // rollback: restaura el snapshot
    avisar("No se pudo guardar");
  } finally {
    invalidar(["dato"]);            // reconciliar, pase lo que pase
  }
}

Reconoce en esta plantilla el esqueleto de lo que la lección cuatro verá encarnado en onMutate, onError y onSettled: no es más que este mismo orden repartido en tres retrollamadas con nombre.

Encapsular el snapshot por operación puede ser tan simple como un mapa indexado por el identificador de cada mutación en vuelo:

// Un snapshot por mutacion en vuelo, indexado por su id
const snapshots = new Map<string, Estado>();

function alMutar(mutId: string, actual: Estado) {
  snapshots.set(mutId, structuredClone(actual)); // su propio pasado
}
function alFallar(mutId: string) {
  restaurar(snapshots.get(mutId)!); // exactamente el pasado que le toca
  snapshots.delete(mutId);
}