STATE THAT SURVIVES A BAD NETWORK.

//The assumption to abandon#

Development happens on a fast, stable connection where requests come back in forty milliseconds and essentially never fail. Real use includes a train tunnel, a congested conference network, and a phone switching from wifi to cellular mid-submit. The code path where a request takes eleven seconds and then fails is not an edge case — on mobile it's a regular Tuesday.

//Three patterns that help#

First, model the request as a state machine rather than a set of booleans. Idle, pending, succeeded, failed, and — importantly — pending-after-failure for a retry. A discriminated union makes contradictory combinations impossible to represent, which matters because "loading and errored" is a state real code produces accidentally and no designer ever drew.

Second, never discard user input optimistically. If someone spent four minutes on a form and the submit fails, their text must still be there. That sounds obvious and is violated constantly, usually because the component unmounted on submit or the store was cleared before the response arrived.

Third, make retry deliberate rather than automatic and invisible. Silent retries on a non-idempotent request produce duplicate orders, and I've seen exactly that. Show the failure, offer the retry, keep the payload.

//How to actually find these#

Throttle your own connection and use your product for a day with a two-second latency and a five per cent failure rate injected. It's an unpleasant day and it surfaces more genuine bugs than a week of feature work. Every project where I've done this has produced at least one finding that would have been a support ticket within a month.