Category
Action
Component Registry
Loading component records...
Component Registry
Component Record
A reusable action button for primary user flows such as form submission, checkout progression, and confirmation actions.
Category
Action
Platform
Cross Platform
Owner
Design Systems
Decisions
2
Interface
Props define how consuming screens configure component behavior, display, and interaction.
| Prop | Type | Required | Description |
|---|---|---|---|
| label | string | Yes | Visible button text announced to assistive technology. |
| variant | 'primary' | 'secondary' | 'danger' | No | Controls visual emphasis and semantic action intent.Default: primary |
| disabled | boolean | No | Prevents interaction and communicates unavailable state visually.Default: false |
State
State records clarify what the component owns internally versus what should be controlled by parent features.
booleanUsed when an async action is pending and the user should not submit again.
Contract
API documentation keeps component behavior aligned with backend expectations and failure states.
Not applicable
Not applicable
Not documented
Not documented
No explicit failure states documented.
This component does not call APIs directly. Parent flows own async behavior and pass loading/disabled state down.
Decision Log
This timeline captures why decisions were made, who made them, and what level of impact they carry.
PrimaryActionButton must render a native button instead of a clickable div.
Rationale: Native buttons provide keyboard support, focus behavior, disabled state, and assistive technology semantics by default.
Comparison Table
Compare each option across the MVP criteria used to justify the final component decision.
| Option | PerformanceRuntime cost, rendering efficiency, and interaction speed. | AccessibilitySemantic support, keyboard behavior, and assistive tech fit. | Bundle SizeImpact on shipped JavaScript and dependency weight. | Developer ExperienceEase of maintenance, testing, reuse, and implementation. |
|---|---|---|---|---|
Native button elementSelectedRender a semantic button element and inherit browser keyboard behavior.
| 5/ 5 | 5/ 5 | 5/ 5 | 4/ 5 |
Clickable divRender a div and manually recreate button interaction behavior.
| 3/ 5 | 1/ 5 | 2/ 5 | 2/ 5 |
Choice made: Use native button element
Logged by Maya Chen on
Loading state should be controlled by the parent feature instead of internal component state.
Rationale: Keeping async ownership outside the UI primitive prevents duplicated business logic and improves testability.
Comparison Table
Compare each option across the MVP criteria used to justify the final component decision.
| Option | PerformanceRuntime cost, rendering efficiency, and interaction speed. | AccessibilitySemantic support, keyboard behavior, and assistive tech fit. | Bundle SizeImpact on shipped JavaScript and dependency weight. | Developer ExperienceEase of maintenance, testing, reuse, and implementation. |
|---|---|---|---|---|
Parent-owned loading stateSelectedLet the feature or parent component own async state and pass loading flags down.
| 4/ 5 | 4/ 5 | 5/ 5 | 4/ 5 |
Internal loading stateLet the button own loading behavior internally after user interaction.
| 3/ 5 | 3/ 5 | 3/ 5 | 3/ 5 |
Choice made: Externalize loading state ownership
Logged by Jordan Lee on