state-machine

Topics in the source

• State machine
• 1. Scope one component
• 2. Find the states in the code
• 3. Build the throwaway page
• 4. Feed each state at the data boundary
• 5. Add the switcher
• 6. Confirm every state renders, then hand over
• Re-check every state after each change

This skill takes one component and renders it on a throwaway page in every state it can be in. Mock data feeds each state, a switcher flips between them and the page is deleted in one step when you are done. It is a workbench, not a review. The page stays up while the user works on the visuals, one state on screen and every other a keypress away. Stacking hostile scenarios on one page for a single look is break, exploring alternative designs is variant and reviewing finished work is interface-review. One component per run: the audit log table, the network panel, the billing card. "The settings page" spans several, so list them and ask which one. Restate it in one sentence: what the component shows, where it renders in production and where its data comes from. The states are the branches the component already has. Read it and its data hooks for every one: | Kind | States | | --- | --- | | Data | Loading, empty, error, one item, a typical set, a set long enough to scroll or paginate, some requests resolved and others pending, stale data refetching | | Account | Plan tier, role and permission checks, an owner versus a member | | Feature | Flags, trials, limits reached, a disabled or l

This is an excerpt. Refer to the complete source and its current requirements.