Optimistic UI: Implementation Patterns

The plain-language idea

Implementing an optimistic update correctly means writing four steps, in this order, every time:

1. Capture the previous value, before touching anything — this is what you'll roll back to if the request fails.
2. Apply the optimistic change to local or cache state immediately, so the UI reflects it before any network response exists.
3. Fire the real mutation request.
4. On success, usually do nothing further (the optimistic value was already correct). On failure, roll back to the captured previous value AND show the user a real signal that it failed — a toast, an inline error, something. Silently reverting with no explanation is a real, common bug: the user saw their action "succeed," then watched it vanish with no reason given, and reasonably assumes the app is broken.

See it in a real thing: a small rollback-capable hook

function useOptimisticMutation<T>(
  current: T,
  setCurrent: (value: T) => void,
) {
  const [pending, setPending] = useState(false);

  async function run(optimisticValue: T, mutate: () => Promise<T>) {
    const previous = current;          // 1. capture
    setCurrent(optimisticValue);       // 2. apply immediately
    setPending(true);

    try {
      const confirmed = await mutate(); // 3. fire the real request
      setCurrent(confirmed);            // 4a. success — reconcile with server truth
    } catch (err) {
      setCurrent(previous);             // 4b. failure — roll back
      showErrorToast("Couldn't save your change. Please try again.");
    } finally {
      setPending(false);
    }
  }

  return { run, pending };
}

// usage: liking a post
const { run } = useOptimisticMutation(post.likeCount, setLikeCount);

function handleLike() {
  run(post.likeCount + 1, () => api.likePost(post.id));
}

The failure branch is doing the actual work this lesson is about. Skipping it — catching the error only to log it, with no rollback and no user-facing signal — is what turns a nice-feeling feature into a UI that lies about what happened.

What people usually miss

Watch out

• The previous value has to be captured before the optimistic change, not after. Capturing it after already overwrites the thing you need for rollback — this ordering bug is subtle because the happy path never exposes it.
• A second optimistic update fired before the first resolves is the real edge case. If update A is still in flight and update B starts, B's own "previous value" needs to be whatever the state was right before B (which now includes A's optimistic change), not the state from before A. Naively rolling back to a single shared "previous" variable on any failure can revert a completely unrelated, still-succeeding change.
• A silent rollback is worse than no optimism at all. The user needs to be told their action didn't stick — an inline error, a toast, anything — not just watch the UI quietly snap back with no explanation.
• "On success, do nothing" is common but not universal. If the server's confirmed value can differ from what was optimistically guessed (a computed field, a server-assigned id), reconciling state with the real response on success matters just as much as rolling back on failure.
• pending/in-flight state still matters even though the UI already looks updated. A double-submit guard (disabling the button while pending) is still needed — the UI looking done doesn't mean the request is done.

Why this matters in interviews

"Show me how you'd actually implement the rollback if this fails" is the natural follow-up once optimistic updates come up, and the strong answer is the capture-apply-confirm-or-rollback shape above, with the second-in-flight-update edge case named unprompted.