domains / families / design / state-machine

state-machine

combined

Model component behaviour as explicit states, events, and transitions. Use when a component has many interacting states that must be exhaustive. For the feel and feedback of a single interaction, use `micro-interaction-spec`. Renders every state of a component you choose on a throwaway page, with mock data and a switcher, so you can work on each state.

When to use

• Modeling UI components as finite state machines
• Defining states, events, transitions, actions, and guards
• Rendering component states on a throwaway page
• Creating mock data for specific component states
• Building a state switcher for visual inspection
• Identifying impossible states to prevent
• Mapping states to UI representations

When not to use

• Micro-interaction feel and feedback
• Stacking hostile scenarios for a single look
• Exploring alternative designs
• Reviewing finished work
• Adding branches to render unreachable states

Skill page

Conflict

The two skills share the name 'state-machine' but perform fundamentally different tasks. The first (Owl-Listener) is a conceptual modeling skill for defining states, events, and transitions to ensure exhaustive behavior coverage. The second (jakubkrehel) is a practical implementation skill for building a temporary 'throwaway' page with a switcher to visually inspect and debug a specific component's states using mock data. They do not reproduce or shorten each other; they address different phases of the design/engineering workflow (specification vs. visualization/debugging).