Implementar actualizaciones optimistas manualmente

Las actualizaciones optimistas manuales comienzan con un estado local del componente inicializado a partir de los datos del servidor: const [items, setItems] = useState(serverItems). Este estado local es lo que renderiza y lo que modificará de forma optimista. NO debe mutar directamente los datos obtenidos del servidor; conserve una copia local que pueda controlar.

Cuando el usuario inicia una mutación (al pulsar «Añadir», «Me gusta» o «Eliminar»), actualice el estado inmediatamente antes de llamar a la API: setItems(prev => [...prev, newItem]). La UI refleja el cambio al instante. Solo después de esta actualización debe enviar la solicitud de red real.

Antes de realizar la actualización optimista, capture el estado actual: const previousItems = items. Esta instantánea es el objetivo de la reversión. Si la llamada a la API falla, restaure este valor. Guárdelo en una variable, no en el estado, ya que solo lo necesita mientras la mutación esté pendiente.

Después de la actualización optimista, realice la llamada a la API de forma asíncrona. Envuélvala en try/catch. Si tiene éxito, puede volver a solicitar los datos opcionalmente para sincronizarlos con el estado del servidor, o confiar en el estado optimista si el servidor devolvería los mismos datos. Si falla, utilice el estado anterior capturado para revertir el cambio.

En el bloque catch de la mutación, ejecute: setItems(previousItems). Esto restaura el estado que había antes de la actualización optimista. Después de la reversión, muestre una notificación de error. Los usuarios entienden que pueden producirse fallos poco frecuentes; lo que no toleran es una incoherencia silenciosa.

Después de revertir el cambio, muestre un mensaje de error: «No se han podido guardar los cambios. Inténtelo de nuevo.» con un botón Reintentar que vuelva a activar la misma mutación. Esto permite que los usuarios decidan cómo actuar. La combinación de reversión, notificación toast de error y reintento gestiona el fallo con elegancia sin bloquear toda la UI.

Al añadir un elemento de forma optimista, el servidor todavía no le ha asignado un ID real. Cree un ID temporal para el elemento optimista: const tempId = crypto.randomUUID(). Utilícelo como clave del elemento en la lista. Cuando la API responda correctamente, sustituya el ID temporal por el ID real asignado por el servidor.

Después de una mutación de creación correcta, el servidor responde con el ID real. Actualice el estado para sustituir el elemento temporal: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Esta conciliación garantiza que las operaciones posteriores utilicen el ID correcto del servidor.

Si el usuario inicia dos mutaciones en rápida sucesión, las respuestas pueden llegar en un orden distinto. La respuesta de la segunda mutación puede llegar antes que la de la primera, y la reversión de la primera podría sobrescribir el estado correcto de la segunda. Esta es una condición de carrera propia de la UI optimista.

Una solución para las condiciones de carrera es serializar las mutaciones mediante una cola. Mientras una mutación está en curso, deshabilite el botón disparador (estableciendo el estado isSubmitting en true). Permita la siguiente mutación solo después de que se complete la anterior. Esto sacrifica algo de capacidad de respuesta, pero garantiza que el estado se actualice en el orden correcto.

Para las operaciones de eliminación: capture los elementos anteriores, filtre el elemento eliminado del estado, llame a la API de eliminación y revierta los cambios si falla. Eliminar es más sencillo que crear (no es necesario reconciliar identificadores), pero se aplican los mismos principios. Considere añadir un breve retraso antes de eliminar (mostrando una opción de "deshacer") antes de realizar la llamada a la API.

¿Por qué los elementos añadidos de forma optimista necesitan un ID temporal?

El patrón manual consiste en capturar previousItems, usar setItems con el nuevo estado, realizar la llamada a la API, revertir los cambios si falla mediante setItems(previousItems) y mostrar un error. Para las adiciones, use crypto.randomUUID() como ID temporal y reconcilie el ID con el del servidor cuando la operación tenga éxito. Evite las condiciones de carrera deshabilitando el disparador mientras haya mutaciones en curso. La combinación de reversión, toast y reintento es la experiencia de usuario estándar para los fallos.