shared-action
A framework-agnostic system for registering, sequencing, and executing actions and workflows — the shared substrate that lets kits define a named action once and run it anywhere, with confirmation prompts and step-driven flows layered on top.
Named actions & workflows
Register an action handler or a multi-step workflow once, then look it up and execute it by id across modules.
State-manager agnostic
A connector interface and factory functions decouple action execution from any specific store, so the same actions run under different runtimes.
Confirmation & resolution
Step-based confirmation flows and an action resolver render dialogs (confirm / input / select) before an action commits.
What it provides
The kit centralises what an action is and how it runs. A registry holds action handlers and named workflows keyed by id; a connector layer (createActionExecutor, createSequenceExecutor, createWorkflowDispatcher) wires those handlers to whatever state manager the host app uses, keeping the action definitions free of store-specific code. On top of that sit the interactive pieces: an action-flow builder for composing flows visually, action-forms (confirmation / input / select-option dialogs), a confirmation flow + service with a global renderer, and an action resolver that drives multi-step resolution with its own pipeline and storage.
Key exports
| Export | Kind | Purpose |
|---|---|---|
registerAction / getActionHandler | fn | Register and look up a named action handler |
registerWorkflow / getWorkflow | fn | Register and look up a named multi-step workflow |
executeWorkflow | fn | Core workflow runner (used by dispatchWorkflow) |
createActionExecutor | factory | Build an executor bound to a state-manager connector |
createSequenceExecutor | factory | Run a sequence of actions in order |
createWorkflowDispatcher | factory | Dispatch a registered workflow by id |
StateManagerConnector / ActionOptions | type | Connector contract + per-action options |
initializeMedicalActions / initializeUIActions | fn | Seed the registry with example medical / UI actions |
registerFormActions / registerSampleWorkflows | fn | Register form-driven actions and sample workflows |
initializeFormActions | fn | Convenience: register form actions + sample workflows together |
ActionFlowBuilder | component | Visual builder for composing action flows |
GlobalConfirmationRenderer | component | App-level renderer for the confirmation service |
ConfirmationForm / InputForm / SelectOptionForm | component | Built-in action-form dialogs |
ActionResolverContainer | component | Host for the step-based action resolver |
How it fits
register* ──▶ registry (actions + workflows, keyed by id)
│
create*Executor ──▶ connector ──▶ host state manager
│
flows: action-forms · confirmation-service · action-resolver
│
▼
runs an action / workflow, with confirm + input steps
Used by: consumed by other frontend kits (it depends on ui-kit,
medical-kit, anddesign-kit) to give them a shared, store-agnostic way to define and run named actions and confirmation flows.
See the Frontend overview for how kits compose, and medical-kit for a domain kit that builds on shared primitives.