Why async workflows need more than isLoading

Many mobile bugs happen because an asynchronous process is represented by a single isLoading boolean.

Real workflows usually have more states: idle, initiating, pending, successful. But they can also become:

• pending, then timed out
• pending, then failed
• pending, then interrupted
• failed, then retrying

I applied this thinking while implementing a transaction flow in one of my projects. The initial request only started the operation; the final result arrived later through a real-time connection.

Instead of treating the entire process as one API call, I modelled each stage explicitly. I also added connection cleanup, timeout handling, retry behaviour and protection against updating an unmounted screen.

This made the UI easier to reason about because every visual state corresponded to an actual system state.

If a process can continue after the first request finishes, it probably deserves a state machine, even if that state machine is implemented with simple React state.