Steps

Usage

The common case uses numeric steps. Completed states are inferred when both active and step keys are numbers.

Best Practices

• Use numeric keys for linear forms and onboarding flows where completion can be inferred.
• Use string keys for named workflows, but set status explicitly for completed or error states.
• Disable future steps when users must complete prerequisites before jumping ahead.
• Treat TxSteps as progress/navigation affordance, not as the source of truth for a router or form state. Keep the authoritative workflow state in the parent.
• Avoid putting long descriptions into every step; use step details below the component when content needs paragraphs or controls.

API Reference

TxSteps Props

TxStep Props

Slots

Events

No events are emitted. Clickable steps update only the internal active step stored by TxSteps.

Overview

• TxSteps renders role="list"; each TxStep renders role="listitem".
• Clickable step heads are native button type="button" elements. Non-clickable heads render as div.
• Disabled clickable steps render disabled buttons and ignore activation.
• Active steps expose aria-current="step" on the head.
• If step is omitted, TxStep registers itself in child order and uses that zero-based index as its key.
• Numeric steps before a numeric active step are treated as completed. String-keyed flows need explicit status="completed" when you want completion styling.
• Clicks update the internal active step but do not emit a change event or update the parent automatically.

Technologies

• State contract: TxSteps owns an internal activeStep and watches the active prop. Clicking a step changes only that internal value; no update:active or change event is emitted.
• Ordering note: Steps register by component uid and child order. Numeric steps infer completed state from effectiveStep < activeStep; string-valued flows need explicit status="completed" when completion should be shown.
• Verified coverage: steps.test.ts covers list/listitem semantics, automatic numeric completion, connector omission on the last item, explicit string steps, click-driven internal active state, and disabled/non-clickable blocking.
• Component sources: packages/tuffex/packages/components/src/steps/src/TxSteps.vue and TxStep.vue.
• Types: packages/tuffex/packages/components/src/steps/src/types.ts exports StepsProps, StepProps, StepsDirection, StepsSize, and StepStatus.
• Export entry: packages/tuffex/packages/components/src/steps/index.ts re-exports from src.
• Coverage: packages/tuffex/packages/components/src/steps/__tests__/steps.test.ts verifies ordering, active state, string steps, connector lines, click behavior, blocking states, and the connector geometry (each size sets only --tx-step-icon-size and the line reads it; the line is a sibling of the marker button and carries tx-step__line--completed after a completed step).
• Visual (2026-09-06): markers sit centred over their own titles and the connector runs from this marker's edge to the next one's (it used to be a flex sibling inside the button, which pushed every marker left of its title); steps ahead are a hollow ring with secondary text, completed and current steps share the primary hue (completed is no longer green) with a 4px halo on the current one, the connector after a completed step takes the same colour, and error has a style of its own.
• Motion (2026-09-06): all CSS, sequenced in reading order — the marker just completed swaps its number for the check (with a small overshoot), the connector after it sweeps towards the next marker (staggered 140ms per step on mount, so a fresh row draws its progress left to right), and the new current marker pops in behind the sweep and then keeps a slow breathing halo; stepping back eases the connector out through a transition rather than snapping. prefers-reduced-motion turns all of it off and keeps the state colours.