Reference
Composables
The logic behind the components, exported on its own — reach for one when you want the behaviour and none of the markup.
Most need nothing else on screen. Four do: useToast and useConfirm need a host to render into, and useForm and useFormField only answer inside the component that provides them. Both cases are covered below.
| Composable | What it gives you |
|---|---|
useDataTable | Sorting, pagination, selection and expansion state, headless |
useAppearance | Light / dark / system, persisted, following the OS |
useElementSize | An element's rendered width and height, observed |
useToast | Raise a toast from anywhere. Needs one IToaster mounted |
useConfirm | A promise-based confirmation. Needs one IConfirmDialog mounted |
useForm / useFormField | What IForm and IFormField provide to the controls inside them |
| Decimal helpers | Add, compare, round and format decimal strings without floating point |
| Date helpers | Convert between ISO YYYY-MM-DD strings and calendar dates |
Imperative APIs
useToast and useConfirm are backed by a module-level store, so they can be called from a plain function with no component in scope — an interceptor, a store action, a route guard.
Each still needs its host mounted once:
useToast→ oneIToasteruseConfirm→ oneIConfirmDialog
The composable creates the state; the host renders it.
Form context
useForm and useFormField are the inject side of a pair. They read what IForm and IFormField provide, so they are useful only inside one.
That is what lets a control you wrote yourself pick up the generated id, the invalid state and the aria-describedby the field has already worked out, without a single prop passed down.