Optimistic UI Updates

Optimistic UI updates the interface as if a request succeeded before the server confirms it. It makes low-risk actions feel instant: starring a repository, toggling a task, reacting to a post, or adding a draft item. The pattern works only when failure can be explained and safely rolled back.

Three State Pattern

Track pending, success, and error separately from the entity itself. The user should be able to tell whether an item is saved or still waiting.

type Todo = {
  id: string;
  title: string;
  status: "pending" | "saved" | "error";
};

export async function addTodoOptimistically(
  todos: Todo[],
  title: string,
  saveTodo: (input: { title: string; idempotencyKey: string }) => Promise<Todo>,
) {
  const idempotencyKey = crypto.randomUUID();
  const tempTodo: Todo = { id: `temp-${idempotencyKey}`, title, status: "pending" };
  const previousTodos = todos;
  const optimisticTodos = [tempTodo, ...todos];

  try {
    const saved = await saveTodo({ title, idempotencyKey });
    return optimisticTodos.map((todo) =>
      todo.id === tempTodo.id ? { ...saved, status: "saved" } : todo,
    );
  } catch {
    return previousTodos;
  }
}

The previous state is your rollback point. Store it before changing local state, then restore it if the server rejects the mutation.

Temporary IDs And Idempotency

New items need a client ID immediately so the UI can render, animate, focus, or remove them while the network request is in flight. Use crypto.randomUUID() to generate a temporary ID and a separate idempotency key. The idempotency key tells the server that retries or double-clicks are the same intended action.

When To Avoid It

Do not use optimistic updates when a rollback would damage trust: payments, irreversible deletion, account security changes, or anything regulated. In those flows, show a clear loading state and wait for confirmation.

Further Learning

Search these terms to go deeper:

• “optimistic UI rollback pattern” — preserving and restoring previous state
• “idempotency key API design” — preventing duplicate server-side actions
• “TanStack Query optimistic updates” — production mutation lifecycle helpers
• “temporary client IDs distributed systems” — reconciling local and server identity

Optimistic UI Updates

When you “like” a post, the heart fills in instantly — it doesn’t wait for the server to reply. That’s optimistic UI: update the screen right away, assuming the action will succeed, and quietly confirm with the server in the background. It makes apps feel snappy.

The idea

Normally: click → wait for server → update screen. (Feels sluggish.)

Optimistic: click → update screen immediately → server confirms in the background. (Feels instant.)

You’re optimistically assuming success — which is usually right.

Handle the rare failure: roll back

Since you updated before the server confirmed, you need a plan for when it fails. The trick: remember the old state, and if the server says “nope,” put it back:

const previous = todos          // save the current state
setTodos([newTodo, ...todos])   // update immediately (optimistic)

try {
  await saveTodo(newTodo)       // confirm with server
} catch {
  setTodos(previous)            // failed? roll back
  showError('Could not save')
}

Show the difference

It’s nice to show whether an item is still pending (saving) vs. saved — a subtle spinner or faded style — so users know the action is in flight.

When NOT to be optimistic

In one sentence

Optimistic UI updates the screen instantly (assuming success) and rolls back if the server fails — great for likes and toggles, but not for payments or irreversible actions, where you should wait for real confirmation.

Want to go deeper?

Switch to Expert mode above for temporary IDs, idempotency keys (preventing double-submits), and TanStack Query’s optimistic helpers.