Alert

In context

Purpose

An Alert carries context the user should notice but isn't forced to act on immediately. Its colour and icon come from the feedback tokens, so it informs — it never punishes. A missed goal or an offline moment is not an error; reserve warning/error for real problems and keep the copy about what to do.

Anatomy

• Icon — a tone-coloured fill glyph (info / success / warning / error).
• Title — the state in a few words.
• Body (optional) — what it means or what to do next.
• Dismiss × (optional) — when the user can clear it.

Variants

• info — neutral context ("Working offline").
• success — something went right, shown in place (not a passing toast).
• warning — a soft problem the user should address ("3 expenses not recorded").
• error — a real failure blocking this step ("Amount missing").

Code

import { Alert } from '@daytwo/components'

<Alert
tone="info"
title="Working offline"
description="Your entries are saved and will sync when you're back online."
/>

When to use

• Offline / sync state on a screen the user is working in.
• Validation that explains what's missing before they can continue.
• A heads-up tied to the content it's about (kept next to it, not floating).

When NOT to use

• A blocking decision — use a Modal.
• A passing confirmation ("Saved ฿1,200") — use a toast / ConfirmationState.
• A tiny status word ("Pending") — use a StatusLabel.

Good vs bad

• Good: error — "Amount missing — enter how much this sale was before saving." Tells the user the exact next action.
• Bad: error — "Validation failed (code 422)". Punishing, internal, and gives the user nothing to do. Also don't paint a missed savings goal red — a coaching nudge is info, not error.

Edge cases

Tokens used