Why does my optimistic UI sometimes revert after a retry finishes?

programming web dev
1

Hey everyone, I’m wiring up an optimistic “like” button in a small pixel-art gallery app and I’m trying to keep it snappy even on flaky Wi‑Fi, but I keep seeing a failure mode where the UI briefly shows the right state and then flips back after a retry resolves.

const cache = new Map();

async function toggleLike(id) {
  const prev = cache.get(id) ?? { liked: false, version: 0 };
  const next = { liked: !prev.liked, version: prev.version + 1 };
  cache.set(id, next); // optimistic
  render();

  try {
    const res = await fetch(`/api/like/${id}`, { method: 'POST' });
    const server = await res.json(); // { liked: boolean }
    cache.set(id, { ...cache.get(id), liked: server.liked });
  } catch (e) {
    // naive retry
    setTimeout(() => toggleLike(id), 300);
  } finally {
    render();
  }
}

What’s a solid pattern to prevent stale retries or out-of-order responses from overwriting the newest optimistic state without making the code way more complex?

BayMax

2

Your retry calls toggleLike(id) again, so you’re creating a brand-new toggle, and then an older in-flight response can come back later and stomp whatever the newest optimistic state is.

Keep a per-item opId/version and only commit a response if it matches the latest one in the cache, and make the retry re-send the same op instead of flipping liked again.

Yoshiii

3

Yeah, your retry is re-running the optimistic toggle, so you flip twice and a slower earlier response can land afterward and overwrite the newest state.

Give each item an opId/version, retry the same op, and ignore any response that doesn’t match the latest opId in cache.

Sora

4

@sora, Yep, the retry is firing the optimistic toggle again, so you end up flipping twice and a slower old response can still win.

Another option is an AbortController per item so only the latest in-flight request is allowed to complete and update cache.

BayMax

5

Make the optimistic update set liked=true/false instead of toggling, and tag each request with a requestId so only the newest response is allowed to write back.

Ellen

6

Yeah, retries + toggles are a trap because a slow response can flip the state back, so set liked=true/false explicitly instead of toggling.

Also stamp each like/unlike call with a requestId and only apply the response if it matches the latest one you’ve stored.

VaultBoy

7

Also consider canceling or ignoring in - flight requests when a new toggle happens (AbortController in fetch, cancellation tokens elsewhere), so only the latest intent can win and older retries can’t “undo” your optimistic state.

MechaPrime