Les Labs / Frontend
FrontendWorking~4h
Optimistic UI that survives a failed request
A small CRUD surface (a task list or comment thread) where every mutation applies to the UI immediately, before the network round-trip resolves. You snapshot prior state before the optimistic update, reconcile with the server's real response on success, and on failure roll the UI back to the exact pre-mutation snapshot while surfacing a visible, specific error toast — not a silent revert the user has to notice on their own.
Ce que ça prouve
La phrase que vous pouvez défendre en entretien.
Ligne de CV
Implemented optimistic UI updates with snapshot-based rollback and visible failure feedback (instant apply, server reconciliation on success, exact-state revert plus toast on failure), proven with a suite that forces the failure path via network mocking.
- Understands optimistic UI is a state machine, not just "update first, ask questions later"
- Designs explicitly for the failure path instead of only demoing the happy path
- Can reason about race conditions between an optimistic update and a slower/failed server response
Le brief
Ce que vous construisez, étape par étape.
- 01Build a list UI (add/edit/delete items) backed by a mock API with a configurable artificial delay and a configurable failure toggle.
- 02On mutation, snapshot the current list state, then apply the change to the UI immediately (before the request resolves).
- 03On server success, reconcile the optimistic item with the server's authoritative response (e.g. real id, server timestamp) rather than trusting the client-generated placeholder forever.
- 04On server failure, roll the UI back to the exact pre-mutation snapshot (not just "remove the new item" — full state restore) and show a toast naming what failed and why.
- 05Prevent a slow, now-stale optimistic update from clobbering a newer successful mutation on the same item (guard with a request/version token).
- 06Disable or visually mark an item as "pending" while its mutation is in flight, so a second edit on the same item is a deliberate action, not an accident.
La preuve
C’est terminé quand ces critères sont validés.
Adding an item updates the UI in the same tick, before the mocked network delay resolves
automated test
Forcing the mock API to fail rolls the list back to the exact pre-mutation state and renders a toast with a specific error message
automated test
A stale in-flight mutation cannot overwrite a newer successful mutation on the same item (version/token guard verified under a simulated race)
automated test
Successful mutation replaces the client-optimistic id/timestamp with the server's authoritative values
automated test
Stack
ReactTypeScriptTanStack Query (or hand-rolled optimistic mutation state)MSW (Mock Service Worker)VitestReact Testing Library
Sage Method
frame → decide → prove
Vous conservez
A working optimistic-UI list app + a Vitest/RTL suite that exercises both the success and forced-failure paths