Idempotent UI actions
Slap yourself if
You assume users only click once and networks only deliver once.
Why this exists
Idempotent UI actions exist because retries, double clicks, replays, optimistic updates, and reconnections are not edge cases. Without idempotency, correct behavior depends on perfect timing — which never happens.
Mental model
An idempotent UI action is safe to repeat. No matter how many times it is triggered, retried, or replayed, the resulting state converges to the same outcome.
- Users trigger the same intent multiple times.
- Requests are retried automatically or manually.
- Optimistic updates replay actions after reconciliation.
- Non-idempotent actions compound effects instead of converging.
- Assuming UI debouncing guarantees single execution.
- Coupling action effects to click count instead of intent.
- Letting retries create duplicate side effects.
- Treating idempotency as a backend-only concern.
Idempotent UI actions are interactions designed so repeated execution produces the same final state, making retries, replays, and duplicate events safe.
- Buttons disabled instead of actions guarded
- Duplicate records after retries
- Optimistic updates that can’t be replayed
- Bugs that only appear under poor network conditions
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.