What drives the button?

Come in, Ben — everyone's gone home. Best hour in the Goodlab... just the hum of the machines, and room to think.

Ben

Staying late, John? ...And that's my code on your screen, isn't it? Is something wrong?

Not wrong — not yet. It's your save button, your first feature. Clean, simple... I like it. Let's read it together.

I see a first piece of state — isSaving.

When the user clicks save, isSaving flips to true. The button follows.

And here — a second piece of state: hasError. When a save fails, you flip it to true — and the button shows the error.

Ben

I tested both, John — the spinner while it saves, the error when it fails. Both work.

What happens when two flags disagree?

Separately, they work — that's what you tested. But there's one thing you didn't realize, Ben. A user clicks save — and mid-save, an error comes back. We flip hasError to true... and nothing stops us. Look at your button: both flags true at once — it spins and shows an error.

We just reached an impossible state — the button is saving and failing at the same time. Every time we set hasError, someone has to remember to flip isSaving back — and nothing enforces it. Two booleans, no rule between them.

How do we make it impossible?

Ben

But... wait. Can't we just reset both flags on every code path? Look — we wrap the save in a try catch, flip the flags on the way in, reset in the try path, and in the catch too.

Thanks Ben — your fix definitely works. The save starts — the try path runs, and completes clean. And if it fails, the catch path resets correctly too. But it only works until someone adds a new code path and forgets to reset.

Let's make a smarter move. Sorry Ben — I'll refactor this from scratch. We delete the patch and declare a single union type called Status.

Our type holds the four possible states: idle, saving, failed and saved — one named value, holding exactly one state at a time.

Now the impossible combination is just... impossible. Not because we remembered to clean up — because the type won't allow it. We can safely move to saving, to saved, to failed, back to idle — button and code in lockstep.

Ben

But... wait a second. Can't we jump straight from idle to failed — without ever passing through saving? Isn't that impossible?

Sharp eyes, Ben. We just found a second problem: impossible transitions.

Button.tsx

1 const [isSaving, setIsSaving] = useState(false)