Optimistic UI And Reconciliation
Optimistic UI updates the screen before the server confirms the operation.
Why This Matters
It can make interfaces responsive, but the client must reconcile authoritative results, conflicts, validation errors, and retries.
Working Model
Optimistic UI updates the screen before the server confirms the operation. Correctness comes from preserving an explicit invariant across every permitted ordering, not from expecting one observed timing.
Roll Back Only The Matching Mutation
let favoriteVersion = 0;
let favorite = false;
async function toggleFavorite() {
const mutationVersion = ++favoriteVersion;
const previous = favorite;
favorite = !favorite;
renderFavorite(favorite);
try {
const response = await fetch("/api/favorite", {
method: "PUT",
body: JSON.stringify({ favorite }),
});
if (!response.ok) {
throw new Error("Request failed: " + response.status);
}
} catch {
if (mutationVersion === favoriteVersion) {
favorite = previous;
renderFavorite(favorite);
showFavoriteError();
}
}
}
The version guard prevents an older failed request from rolling back a newer user action.
Practical Rules
- Assign temporary client IDs.
- Store enough prior state to roll back.
- Replace optimistic records with authoritative responses.
- Model pending, confirmed, failed, and conflict states.
- Do not optimistically expose security-sensitive success.
Failure Modes
- Assuming the server will assign the same values.
- Rolling back over a newer user edit.
- Treating timeout as definite failure.
- Hiding conflict resolution from users.
Verification
- Test success, rejection, timeout, and delayed success.
- Test edits made while pending.
- Assert temporary IDs are replaced once.
- Log reconciliation failures.
What You Should Be Able To Do
After this lesson, you should be able to explain optimistic state, rollback, authoritative reconciliation, and conflict presentation, choose a suitable approach for a real PHP project, and verify the result instead of relying on assumptions.
Practice
Practice: Create An Optimistic Comment
Design an optimistic comment creation flow.
Your answer must:
- state the intended outcome;
- show the commands, data flow, or implementation shape;
- identify at least one unsafe alternative;
- explain how the result will be verified.
Show solution
Create a temporary ID and pending record, submit with an operation ID, replace it with the server record on success, and retain editable failed state on validation failure.
The important part is not memorising one command or vendor screen. The solution makes the invariant, failure behavior, and verification evidence explicit.
Practice: Roll Back A Toggle
A favorite toggle is optimistically changed but the server rejects it.
Your answer must:
- state the intended outcome;
- show the commands, data flow, or implementation shape;
- identify at least one unsafe alternative;
- explain how the result will be verified.
Show solution
Associate the response with the mutation version. Roll back only if no newer toggle superseded it, then show a recoverable error.
The important part is not memorising one command or vendor screen. The solution makes the invariant, failure behavior, and verification evidence explicit.
Practice: Handle A Version Conflict
An optimistic profile edit receives a version conflict.
Your answer must:
- state the intended outcome;
- show the commands, data flow, or implementation shape;
- identify at least one unsafe alternative;
- explain how the result will be verified.
Show solution
Keep the user's draft, fetch or use the current server representation, present changed fields, and let the user merge or retry against the new version.
The important part is not memorising one command or vendor screen. The solution makes the invariant, failure behavior, and verification evidence explicit.