Why it matters
Interface and workflow code tends to grow into a tangle of flags: isLoading, hasError, isSubmitting, all true at once in some combination nobody planned. Writing down the states first, and which events move between them, makes those impossible combinations impossible. The catch is that statechart tools are often heavy, online-only, or tied to one library.
This designer uses a few lines of plain text: a state per line, indented for child states, and EVENT -> target [guard] / action under each. It draws the chart as nested boxes, lets you send events and watch exit and entry actions run in the order the SCXML standard uses (including parallel regions and history), and checks the machine for the usual logic bugs: states nothing leads to, states nothing leads out of, compound states without an initial child, transitions to states that don't exist, and two handlers for the same event. When it's right, copy XState v5 code, a Mermaid diagram for your docs and TypeScript types. Paste an existing XState config to review it: it's read as data, never run.
How it works
- InputStates and events in a few lines
- In your browserChecked, drawn and simulated
- OutputXState v5, Mermaid and TypeScript
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| State | Own transitions |
|---|---|
| cart | 2 |
| details | 2 |
| payment | 2 |
| payment.card | 1 |
| payment.paypal | 1 |
| processing | 3 |
| failed | 2 |
| done | 0 |
| giftWrap | 1 |
How to use it
- Write the states and transitions, or paste an XState createMachine config.
- Fix anything in the problems table.
- Click events in the simulator; type a guard name to make it false.
- Copy the XState, Mermaid or TypeScript output.
FAQ
What syntax does it use?
One state per line ending in a colon, indented under its parent. Under a state: EVENT -> target, optionally [guard] and / action. initial name sets the starting child, entry: and exit: list actions, and after 5s -> target is a delayed transition. Add final, parallel or history after the colon.
Is the XState output ready to use?
It's XState v5 setup() code with typed events and placeholder guards and actions for you to fill in. Targets use sibling names where possible and #id paths otherwise, so it runs as it is.
Can it read my existing XState machine?
Yes, as a literal: states, initial, on, after, always, entry, exit, guards and actions. It's parsed as data (JSON5-style), so functions and imports are shown by name and nothing is executed.
What counts as a dead end?
A state that isn't final and has no transition out of it, including transitions inherited from its parent states. A state that only loops back to itself counts too.
How does the simulator pick transitions?
Like XState and SCXML: starting from each active state, the innermost state with a matching event whose guard passes wins. States are exited innermost first and entered outermost first, with their actions logged in that order.
