Implementing Optimistic Updates Manually

Manual optimistic updates start with local component state initialized from server data: const [items, setItems] = useState(serverItems). This local state is what you render, and it is what you will mutate optimistically. You should NOT mutate server-fetched data directly — keep a local copy you control.

When the user triggers a mutation (clicking "Add", "Like", "Delete"), perform the state update immediately before calling the API: setItems(prev => [...prev, newItem]). The UI reflects the change instantly. Only after this update do you fire the actual network request.

Before making the optimistic update, capture the current state: const previousItems = items. This snapshot is your rollback target. If the API call fails, you restore this value. Store it in a variable (not state) since you only need it for the duration of the pending mutation.

After the optimistic update, make the API call asynchronously. Wrap it in try/catch. On success, you can optionally refetch to sync with the server state, or trust the optimistic state if the server would return the same data. On failure, use the captured previous state to rollback.

In the catch block of your mutation: setItems(previousItems). This restores the state to what it was before the optimistic update. Follow the rollback with an error notification. Users understand that rare failures happen — what they cannot tolerate is a silent inconsistency.

After rolling back, display an error message: "Could not save changes. Please try again." with a Retry button that re-triggers the same mutation. This gives users agency. The combination of rollback + error toast + retry covers the failure case gracefully without blocking the entire UI.

When adding a new item optimistically, the server has not yet assigned a real ID. Create a temporary ID for the optimistic item: const tempId = crypto.randomUUID(). Use this as the item's key in the list. After the API responds successfully, replace the temp ID with the server-assigned real ID.

After a successful creation mutation, the server responds with the real ID. Update your state to replace the temporary item: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). This reconciliation ensures subsequent operations use the correct server ID.

If the user triggers two mutations in rapid succession, the responses may arrive out of order. The second mutation's response may arrive before the first, and the rollback of the first could overwrite the correct state from the second. This is a race condition unique to optimistic UI.

One solution to race conditions: serialize mutations using a queue. While a mutation is in-flight, disable the trigger button (setting isSubmitting state to true). Only allow the next mutation after the previous one completes. This sacrifices some responsiveness but guarantees correct state ordering.

For delete operations: capture previous items, filter out the deleted item from state, call the delete API, and rollback on failure. Delete is simpler than create (no ID reconciliation) but the same principles apply. Consider adding a brief delay before the delete (showing an "undo" option) before making the API call.

Why do optimistically added items need a temporary ID?

The manual pattern: capture previousItems, setItems with the new state, make the API call, rollback on failure with setItems(previousItems) and show an error. For additions, use crypto.randomUUID() as a temp ID and reconcile with the server ID on success. Prevent race conditions by disabling the trigger during in-flight mutations. Rollback + toast + retry is the standard failure UX.