Conflictos y UX: los límites del optimismo

El optimismo del caso feliz es la parte fácil: predices, aciertas, reconcilias, y nadie nota la costura. Su verdadera madurez se revela en los bordes, donde la apuesta se tuerce. ¿Qué ocurre si mientras tu predicción viaja, otro cliente cambió el mismo dato y el servidor te rechaza por conflicto? ¿Cómo le dices al usuario que su cambio aún no está confirmado sin arruinar la sensación de inmediatez que perseguías? ¿Y cuándo, sencillamente, no deberías ser optimista en absoluto? Esta lección cierra el nivel con las tres cuestiones que separan un optimismo de juguete de uno de producción: los conflictos entre cambios, la experiencia honesta del estado en vuelo, y el criterio para reconocer las operaciones donde adelantarse es un error. El optimismo, veremos, no es un interruptor que se enciende por defecto, sino un contrato que hay que honrar entero o no firmar.

Cuando dos cambios chocan

El optimismo asume implícitamente que eres el único que toca el dato, pero en un sistema real varios clientes, o varias pestañas del mismo usuario, mutan el mismo recurso a la vez. Tu predicción parte del estado que tú viste, mientras el servidor ya avanzó a otro. Cuando tu petición llega, el servidor puede detectar que la editaste sobre una versión obsoleta y rechazarla con un conflicto de concurrencia —el clásico código 409— en lugar de aplicarla a ciegas. Los mecanismos habituales son un número de versión o un identificador de revisión, a menudo transportado como ETag, que el servidor compara: si no coincide, tu escritura llega tarde.

// Concurrencia optimista: el cliente declara la version que creyo editar
const res = await fetch(url, {
  method: "PUT",
  headers: { "If-Match": etag }, // la revision base sobre la que edite
  body: JSON.stringify(cambio),
});

if (res.status === 409) {
  const fresco = await api.leer(url); // el mundo cambio: trae lo nuevo
  resolverConflicto(cambio, fresco);   // fusionar, preguntar o descartar
}

Fíjate en que esta es la misma idea de concurrencia optimista que abría el nivel, ahora del lado del servidor: cada quien procede como si nadie más tocara el dato y el conflicto se valida al final, cuando la escritura aterriza.

Las estrategias de resolución forman un abanico: desde el simple “gana la última escritura”, que descarta silenciosamente el cambio perdedor y es aceptable para datos triviales, hasta la fusión de cambios o la intervención explícita del usuario cuando el dato es valioso. Elegir mal aquí produce el peor bug del optimismo: la pérdida silenciosa de trabajo ajeno.

La experiencia del estado en vuelo

Entre la predicción y la confirmación existe una ventana en la que el resultado se muestra pero no está garantizado, y la interfaz debe ser honesta sobre esa incertidumbre sin sabotear la inmediatez que era su razón de ser. El equilibrio es fino: si no señalas nada, engañas al usuario haciéndole creer que algo confirmado cuando aún no lo está; si plantas un spinner sobre cada acción, anulas la ventaja de haberte adelantado y vuelves al pesimismo con pasos extra.

flowchart LR
A[accion del usuario] --> B[render optimista con senal guardando]
B --> OK[confirmacion: retirar senal, estado guardado]
B --> ERR[fallo: rollback con aviso y reintento]
style OK fill:#a6e3a1,color:#11111b
style ERR fill:#f38ba8,color:#11111b

El caso del fallo merece el mayor cuidado. Una reversión silenciosa es la peor experiencia posible: el usuario vio su acción surtir efecto y luego desaparecer sin explicación, y no sabe si debe reintentar, si perdió datos o si la aplicación está rota. Comunicar el fallo con un mensaje claro y un reintento a mano transforma un momento de desconfianza en uno de control.

Modelar esos tres estados como un tipo mantiene la interfaz honesta, porque obliga a decidir qué se muestra en cada uno en lugar de olvidar el caso incómodo:

type EnVuelo = "guardando" | "guardado" | "fallido";

function Fila({ texto, estado, onReintentar }) {
  return (
    <li style={{ opacity: estado === "guardando" ? 0.5 : 1 }}>
      {texto}
      {estado === "guardando" && <small> guardando...</small>}
      {estado === "fallido" && <button onClick={onReintentar}>reintentar</button>}
    </li>
  );
}

Cuándo NO ser optimista

El cierre del nivel es un ejercicio de criterio, porque la técnica más avanzada incluye saber cuándo no usarla. Tres condiciones desaconsejan el optimismo. La primera es la irreversibilidad y el alto coste: un pago, un borrado con efectos en cascada, cualquier acción donde equivocarse sea caro o embarazoso; ahí la ansiedad de un spinner honesto vale más que la falsa calma de un optimismo que habrá que desmentir. La segunda es la impredecibilidad: si el cliente no puede calcular el resultado sin el servidor, no hay predicción que mostrar. La tercera es la alta tasa de fallo: sobre una red inestable o un endpoint frágil, revertir constantemente es más desconcertante que esperar de entrada.

Basta con que se cumpla una de las tres para que el optimismo deje de ser un regalo y pase a ser un riesgo. El árbol de decisión lo condensa: solo el camino que sortea las tres trampas llega a la casilla donde el contrato se puede firmar.

flowchart TD
Q1[el resultado es predecible en el cliente?] -->|no| PES[se pesimista, espera al servidor]
Q1 -->|si| Q2[el fallo es reversible y barato?]
Q2 -->|no| PES
Q2 -->|si| Q3[la tasa de exito es alta?]
Q3 -->|no| PES
Q3 -->|si| OPT[se optimista con contrato completo]
style OPT fill:#a6e3a1,color:#11111b
style PES fill:#89dceb,color:#11111b