Traffic Light FSM Visualizer — Free JS State Machine Snippet

A finite state machine (FSM) is one of the oldest and most reusable ideas in software: a system has a fixed set of named states, it is only ever in exactly one of them at a time, and it moves between states through well-defined events. This snippet makes that abstract idea concrete by pairing a live node-and-arrow diagram with an actual working traffic light, so the diagram and the UI move in perfect lockstep — click "Next transition" and watch the same change happen in the graph, the physical-looking signal head, and a plain-English transition table at the same time.

The data model is the whole lesson

Everything is driven by one object: TRANSITIONS, keyed by current state name, where each entry is an array of { event, next } pairs describing which events are valid from that state and which state they lead to. RED only accepts timer_expired and only ever goes to RED_YELLOW. There is no giant if/else chain and no scattered boolean flags like isRed, wasYellow, pedestrianTurn — a single lookup table is both the documentation and the executable logic. This is exactly the shape you would use for an order-status pipeline (PENDING → PAID → SHIPPED → DELIVERED), a multi-step signup wizard, a media player's play/pause/buffer states, or a game character's idle/walk/attack states. Once you see the pattern here you can lift the TRANSITIONS object structure directly into any of those problems.

Six states, not three

Most "traffic light" demos stop at red/yellow/green, but a real intersection controller has more nuance: this one adds a RED_YELLOW transitional state (used in many countries to warn drivers the green is coming) and a full pedestrian cycle (WALK / DONT_WALK) that shares the red phase. Modeling six states instead of three is what makes the FSM pattern legible — with only three states it is tempting to just cycle an array index, but six states with asymmetric behavior (the walk sign only changes during the red phase) forces you to actually use the event/transition lookup rather than a shortcut.

Drawing the diagram procedurally with SVG

The graph is not hand-drawn markup — buildDiagram() reads a LAYOUT object mapping each state name to an (x, y) coordinate, then generates SVG <circle>, <text>, and curved <path> elements with document.createElementNS. Edge curves use a quadratic Bezier whose control point is offset perpendicular to the straight line between two nodes (midX/midY nudged along the normal direction (dy/dist, -dx/dist)), which is what keeps the arrows visually separated instead of overlapping straight lines. Arrowheads are SVG <marker> elements referenced by marker-end, so the arrow head recolors automatically when the active class swaps the path's stroke color — no separate arrowhead element to keep in sync.

Highlighting active state and the just-taken transition

Every state transition calls a single paint() function that toggles an .active class based on a simple dataset comparison (el.dataset.state === current), applied identically to the SVG nodes, the SVG edges, and the transition table rows. Because all three views read from the exact same current variable and the exact same class-toggle logic, the diagram, the table, and the signal light can never visually disagree with each other — there is only one source of truth.

Driving a real signal head from the same state

The physical-looking signal — three lamp <div>s with a glow effect from box-shadow, plus a separate pedestrian sign — is just another consumer of current. paint() maps each of the six state names to which lamps get the .on class and what the walk sign shows, meaning the visual traffic light is not simulated independently; it is a direct rendering of the same FSM state that drives the diagram. This is the same separation you would use in production: one authoritative state variable, and any number of "view" functions that render from it.

Manual stepping and timed auto-play

step() looks up the single valid transition for the current state, updates current, calls paint(), and logs the event that fired. setAuto() wraps that same step() call in a setInterval, so auto-play is not a separate code path — it is the identical transition function fired on a timer instead of a click. Toggling auto-play off calls clearInterval and nulls the timer reference, which matters when porting this into a component framework: that timer must be torn down on unmount or it keeps firing against a detached DOM.