Feedback

Something happened. The person needs to know. There are five ways to tell them, and the wrong one is either not noticed or in the way. Pick by what happened, not by what looks nice.

Toast: brief, never blocking

1<script lang="ts">2	import { Button, toast } from 'omaris';3</script>4​5<Button variant="tonal" onclick={() => toast('Copied to clipboard')}>Plain</Button>6<Button variant="tonal" tone="success" onclick={() => toast.success('Invoice sent')}>Success</Button7>8<Button variant="tonal" tone="destructive" onclick={() => toast.error('Upload failed')}>9	Error10</Button>11<Button variant="tonal" tone="warning" onclick={() => toast.warning('Card expires soon')}>12	Warning13</Button>

Most actions get no toast. One reports work that finished and left nothing on screen to see — "Copied", "Invite resent", "12 rows archived". A press whose result is visible reports itself, and a control that would only announce its own name needs no feedback at all. Toasts stack, and on a phone a handful of them are the whole viewport.

Creating something is the case people toast by reflex and should not: add a product and the product is in the list, so the list already said it. The same goes for a rename, a delete, a toggle, a filter, an opened panel and a sent message — the screen changed, which is a better confirmation than a strip of text over it. What is left, and what a toast is genuinely for:

A toast is for a result the person did not need to wait for. It never asks a question — there is no "Are you sure?" toast — and it never carries the only copy of something important, because it will be gone in four seconds.

• toast.success('Saved') for the common case; toast.error(…) for a failure.
• toast.promise(save(), { loading: 'Saving…', success: 'Saved', error: 'Could not save' }) follows a request from start to end, in one toast.
• One action at most — "Undo", "Retry", "View". An undo toast is the right way to make a delete safe without a dialog.

1<script lang="ts">2	import { Button, toast } from 'omaris';3​4	const save = (ok: boolean) =>5		new Promise<string>((resolve, reject) =>6			setTimeout(() => (ok ? resolve('storefront') : reject(new Error('timeout'))), 1500)7		);8</script>9​10<Button11	variant="tonal"12	onclick={() =>13		toast.promise(save(true), {14			loading: 'Deploying…',15			success: (name) => `${name} is live`,16			error: 'Deploy failed'17		})}18>19	Deploy20</Button>21​22<Button23	variant="tonal"24	tone="destructive"25	onclick={() =>26		toast.promise(save(false), {27			loading: 'Deploying…',28			success: 'Live',29			error: 'Deploy failed'30		})}31>32	Deploy, badly33</Button>

Alert: stays until it is not true

1<script lang="ts">2	import { Alert } from 'omaris';3</script>4​5<div class="flex w-full flex-col gap-3">6	<Alert tone="info" title="Scheduled maintenance" description="Sunday 2–3 AM UTC." />7	<Alert tone="success" title="Deploy finished" description="storefront is live." />8	<Alert tone="warning" title="Card expiring" description="Update it before 1 April." />9	<Alert tone="destructive" title="Build failed" description="3 tests are red on main." />10</div>

An alert belongs to the page. It is the right answer for a condition rather than an event: the account is over its limit, the connection is offline, this record is read-only. It has a tone, an optional action, and it can be dismissed if the condition can be ignored. A destructive alert announces itself to a screen reader immediately; the rest wait their turn.

Dialog: a decision

1<script lang="ts">2	import { Button, dialog, toast } from 'omaris';3​4	async function remove() {5		const ok = await dialog.confirm({6			title: 'Delete this project?',7			description: 'Everything in it goes too. This cannot be undone.',8			confirmText: 'Delete',9			destructive: true10		});11		if (ok) toast.success('Project deleted');12	}13​14	async function rename() {15		const name = await dialog.prompt({ title: 'Rename project', value: 'storefront' });16		if (name) toast('Renamed to ' + name);17	}18</script>19​20<Button variant="tonal" tone="destructive" onclick={remove}>Delete…</Button>21<Button variant="tonal" onclick={rename}>Rename…</Button>

A dialog stops everything, so it earns that by asking something. The provider gives you the three shapes as promises, which is how most of them should be written:

if (await dialog.confirm({ title: 'Delete this order?', destructive: true })) remove();const name = await dialog.prompt({ title: 'Rename', value: current });await dialog.alert({ title: 'Saved', description: 'Your changes are live.' });

A dialog for a task — editing, filtering, a long form — is a Sheet: it keeps the page in view and becomes a bottom sheet on a phone.

Progress: something is coming

1<script lang="ts">2	import { Progress } from 'omaris';3</script>4​5<div class="flex w-full max-w-md flex-col gap-6">6	<Progress value={72} label="Uploading" />7	<Progress label="Working" />8	<Progress value={40} tone="success" size="lg" label="Large, success" />9</div>

A bar when you know how far along it is; the indeterminate bar when you only know it is working; a skeleton when what is coming has a shape. A spinner on a button (loading) is the same idea at the scale of one action. Never show two of these for one thing.

When to confirm

Confirm when the action is destructive and cannot be undone: deleting, signing out of every device, sending to a thousand people. Everywhere else, do the thing and offer an undo in the toast — a confirmation dialog on every action trains people to click through it, and then it stops protecting the one that mattered.

• Name the action in the button: "Delete order", not "OK".
• Say what will happen, once, in the description.
• destructive: true paints the confirm button red. The safe choice is the quiet one.

The whole thing on one screen

The admin pattern at /patterns/dashboard has all of it: toasts on save, an alert for a failed sync, a confirm on delete, skeletons while the table loads, and an empty state when a filter matches nothing.