Actualizaciones optimistas: aplicar antes de saber y revertir con precisión

La lección anterior guardaba el pasado para poder volver a él por voluntad del usuario. Esta lo guarda para poder volver a él por culpa de la red, y la diferencia entre ambos casos es lo que hace difícil el segundo. Una actualización optimista consiste en aceptar que la interfaz no debe esperar a la confirmación del servidor para mostrar el resultado: aplicas el cambio en el mismo fotograma de la pulsación, envías la petición, y solo si falla revocas lo que habías mostrado. La apuesta es sensata porque las peticiones que un usuario inicia deliberadamente se cumplen la inmensa mayoría de las veces, y el premio es una interfaz sin latencia percibida. Pero el diseño no lo determina el caso feliz, que es trivial, sino el minoritario: hay que revertir un cambio concreto en un estado que ya no es el que había cuando lo aplicaste, y hacerlo sin destruir el trabajo que el usuario hizo entretanto.

La apuesta y su contrato

Toda actualización optimista es una predicción: el cliente calcula el estado que cree que tendrá el servidor cuando la operación termine, y lo muestra ya. Que esa predicción sea legítima depende de una condición que conviene enunciar sin ambigüedad, porque es la que separa el patrón de la temeridad: el cliente debe poder computar el resultado con la información que tiene, y la operación debe tener una probabilidad de éxito muy alta. Marcar un mensaje como leído, dar a me gusta, renombrar un elemento o reordenar una lista cumplen ambas; cobrar una tarjeta, reservar el último asiento de un vuelo o aplicar un cupón cuyo descuento calcula el servidor no cumplen ninguna de las dos, porque el resultado no es predecible localmente y el fallo no es raro.

El contrato tiene tres finales y los tres deben estar escritos antes de aplicar nada. El primero es la confirmación, en la que el servidor devuelve el estado real y el cliente reconcilia su predicción con él —que no siempre coinciden, aunque la operación haya tenido éxito—. El segundo es el rechazo, en el que hay que revocar el cambio y decírselo al usuario de forma que entienda qué se ha deshecho. El tercero, el que casi todo el mundo olvida, es la indeterminación: la petición no responde, el navegador se queda sin red, la pestaña se cierra. Ese tercer final no admite una respuesta automática correcta, y la decisión de qué hacer con él —reintentar, encolar, revertir tras un tiempo límite— es de producto, no de infraestructura.

Revertir un cambio, no restaurar un estado

La implementación ingenua guarda una copia del estado antes de aplicar el cambio y, si la petición falla, la restaura. Es incorrecta, y la razón es exclusivamente temporal: entre la aplicación y el fallo transcurren cientos de milisegundos durante los cuales el usuario ha seguido usando la aplicación y el servidor ha podido enviar datos nuevos. Restaurar la instantánea revierte también todo eso, de modo que el fallo de una petición borra trabajo que no tenía nada que ver con ella. El síntoma es característico y desconcertante: el usuario marca un elemento, escribe en otro campo, falla la red, y lo que había escrito desaparece.

Lo correcto es tratar la reversión como la aplicación del inverso de un cambio concreto, no como un salto en el tiempo. Es la misma distinción que en control de versiones separa revertir un commit de restablecer la rama a un punto anterior: lo primero compone con el trabajo posterior, lo segundo lo aniquila. En la práctica esto significa registrar el parche que la actualización optimista produjo —qué rutas del estado tocó y qué valor tenían— y aplicar su inversa si hace falta. RTK Query lo expone directamente con el resultado del parche y su método undo, e Immer lo ofrece de forma general con los parches inversos que puede emitir al producir cualquier estado.

// RTK Query: el parche optimista y su reversion precisa.
const api = createApi({
  endpoints: (build) => ({
    marcarLeido: build.mutation<void, { id: string }>({
      query: ({ id }) => ({ url: `/mensajes/${id}/leido`, method: 'POST' }),
      async onQueryStarted({ id }, { dispatch, queryFulfilled }) {
        const parche = dispatch(
          api.util.updateQueryData('listarMensajes', undefined, (borrador) => {
            const m = borrador.find((x) => x.id === id)
            if (m) m.leido = true
          }),
        )
        try {
          await queryFulfilled
        } catch {
          parche.undo() // revierte SOLO esta mutacion, no el estado entero
        }
      },
    }),
  }),
})

Cuando no usas una capa de datos que te dé el parche hecho, la pieza que necesitas es la emisión de parches inversos de la librería de inmutabilidad. Al producir un estado nuevo puedes pedir a la vez la lista de operaciones que lo generaron y la lista que lo desharía, guardar la segunda asociada al identificador de la operación en vuelo, y aplicarla si la petición falla. La ventaja sobre la instantánea es exactamente la misma que antes y ahora es explícita en el código: lo que guardas no es un estado, es una diferencia.

import { produceWithPatches, applyPatches, enablePatches } from 'immer'
enablePatches()

const [siguiente, parches, inversos] = produceWithPatches(estado, (b) => {
  b.mensajes[id].leido = true
})
// Guardar `inversos` junto al identificador de la operacion en vuelo.
// Al fallar: applyPatches(estadoActual, inversos) — compone con lo ocurrido despues.

Identidad temporal: crear antes de que exista

Cuando el usuario crea algo, la interfaz debe mostrarlo de inmediato, pero el identificador canónico lo asigna el servidor. El cliente necesita entonces una identidad provisional que le permita renderizar, referenciar y eventualmente borrar la entidad antes de saber cómo se llama de verdad. La solución estándar es generar un identificador temporal en el cliente, insertar la entidad con él y marcarla como pendiente, y al confirmar sustituir la identidad temporal por la definitiva en la colección y en todo lo que apunte a ella.

Esa sustitución es la parte que se subestima. Si el estado está normalizado, la entidad vive en un mapa por identificador y puede haber referencias a ella desde otras entidades, desde una selección activa, desde una ruta de navegación o desde otra operación optimista en vuelo. Cambiar la clave obliga a reescribir todas esas referencias de forma atómica; olvidarse de una produce un puntero colgante que rompe al deshacer o al borrar. La alternativa que muchos equipos acaban adoptando es más limpia: generar el identificador definitivo en el cliente con un formato que el servidor acepte y respete, de modo que la entidad nazca con su nombre final y la reconciliación se limite a completar campos.

flowchart TD
U[usuario pulsa] --> A[aplicar parche optimista]
A --> R[render inmediato]
A --> P[enviar peticion]
P --> OK{respuesta}
OK -->|exito| C[reconciliar con datos del servidor]
OK -->|error| D[aplicar parche inverso y avisar]
OK -->|sin respuesta| T[decidir: reintentar encolar o revertir]
style C fill:#a6e3a1,color:#11111b
style D fill:#f38ba8,color:#11111b
style T fill:#f9e2af,color:#11111b

// Identidad definitiva generada en el cliente: la reconciliacion se vuelve trivial.
const id = crypto.randomUUID()
dispatch(tareas.anadida({ id, titulo, pendiente: true, operacion: id }))
try {
  const real = await api.crear({ id, titulo })
  dispatch(tareas.confirmada({ id, cambios: real })) // reconcilia, no confirma
} catch {
  dispatch(tareas.borrada(id))                       // el inverso conoce a quien borrar
}

Queda un detalle que distingue una implementación cuidadosa de una descuidada: la confirmación no es una operación vacía. Aunque la petición tenga éxito, el estado que devuelve el servidor puede diferir de tu predicción en campos que el cliente no podía conocer —marcas de tiempo, contadores agregados, números de versión, valores normalizados o truncados—. Descartar la respuesta porque la operación fue bien deja la interfaz mostrando una predicción que ya nadie va a corregir, y esa divergencia silenciosa sobrevive hasta la siguiente recarga. La regla es que el éxito reconcilia, no confirma.

Concurrencia y el criterio para no ser optimista

Antes de la concurrencia hay una decisión de representación que condiciona todo lo demás: cómo distingue tu estado un dato confirmado de uno apostado. La forma pobre es no distinguirlos, y produce aplicaciones que persisten predicciones en disco, las envían a otras pestañas y las usan como base para calcular la petición siguiente. La forma correcta es marcar la entidad o el campo como pendiente mientras haya una operación en vuelo sobre él, con el identificador de esa operación, de modo que la interfaz pueda atenuarlo, impedir acciones destructivas sobre él y saber a quién pertenece cada parche. Ese registro de operaciones en vuelo es además el índice que la reversión necesita para ser precisa.

Varias operaciones optimistas sobre la misma entidad se solapan con normalidad, y ahí aparece el fallo más difícil de reproducir de todo el patrón. Si el usuario pulsa dos veces sobre el mismo interruptor, hay dos peticiones en vuelo y dos parches aplicados; si la primera falla y la segunda tiene éxito, revertir la primera restaura un valor que la segunda ya había superado. La respuesta correcta no es evitar el solapamiento sino ordenarlo: revierte solo si el parche que vas a deshacer sigue siendo el último aplicado sobre esa entidad, y descarta la reversión si otro cambio posterior ya la ha dejado obsoleta. Cuando el orden importa de verdad, la solución robusta es serializar por entidad con una cola que garantice que sobre un mismo objetivo no hay nunca dos peticiones simultáneas.

Conviene además elegir con criterio la unidad de agrupación de las peticiones, porque el solapamiento se puede reducir en origen. Un interruptor que el usuario pulsa repetidamente no necesita una petición por pulsación: necesita que la interfaz responda a cada una y que la red reciba solo el estado final tras una breve espera. Aplicar el cambio optimista siempre y retrasar el envío es la combinación que da lo mejor de ambos mundos, y reduce el número de reversiones posibles a una por ráfaga en lugar de una por pulsación. La regla que ordena el reparto es simple: la interacción es inmediata, la red es agrupada, y entre ambas hay un único parche vivo por entidad.