Who fired the side effects?

Oh George — of course you're right. But don't rush us: things build slowly here in the Goodlab. One more time, we reach for the simple fix. The handler sends events around, and fires the side effects along the way — it calls the API, clears the error, bumps the counter.

The machine moves to saving. Can it tell you what fired along the way?

It can't. Those effects live in the handler, invisible to the graph. And it gets worse, Ben: every new caller has to remember to fire them — discipline doesn't scale, and none of it is easy to test. The machine knows where it is — not what it did to get there.

Ben

John... I see the pattern now. The machine should own the actions too, right? Every time we add a caller, we duplicate the effects. The machine should be self-contained.

You are exactly right, Ben. And at this point — we should ask for some help. States, events, context, guards, and now actions — this exact model already exists as a battle-tested TypeScript library called XState.

Where do effects belong?

XState gives effects a first-class home, attached right to the transition. It calls them actions. Each action lives on the edge that owns it — when the edge fires, the action fires.

Let's walk the flow now. When the SAVE event fires, the machine moves to saving and startRequest runs. When the request fails, we land in failed and incrementRetries bumps the count. A retry crosses back into saving, firing startRequest again. And on success, we land in saved and clearError wipes the slate. Each action rides the edge that owns it.

The effects are part of the graph now. Read the machine and you can see everything — every state, every rule, every effect. But none of it runs on its own. Defining a machine and running one are two different things.

handler.ts

1 async function handleSave() {

2 send({ type: 'SAVE' })

3 try {

4 await api.save()

5 send({ type: 'SUCCESS' })

6 clearError()

7 } catch {

8 send({ type: 'FAIL' })

9 incrementRetries()

10 }

11 }