Communicate task outcomes and actionable changes without unnecessary interruption.
Notifications tell people about a result or change that deserves attention. Keep routine feedback near the affected content and reserve interruption for situations that require a decision before the task can continue.
This page describes in-application feedback. Liquidify does not supply browser push delivery, permission requests, scheduling, or an operating-system notification center. Apple's notification guidance informs urgency and relevance; its platform delivery settings are not Liquidify APIs.
| Need | Starting point |
|---|---|
| A local outcome or recoverable problem | Banner or concise status text near the task |
| A persistent condition on an item | Status indicators |
| A decision that must interrupt work | Dialogs |
| Progress while work continues | Loading |
Banner provides a title, optional message, severity, actions, and dismissal. With its default live={true}, warning and error statuses render an alert role; other statuses render a status role. live={false} produces a named region for static content, such as information present at page load.
Figure in preparation
Notifications: component composition
A retry message stays available until the outcome is known.
For a failed save, use “Changes could not be saved” and explain that the draft remains available. Offer “Try again” only when retry is supported. Dismissing that message hides the presentation; it does not save the draft or resolve the failure.
Banner actions have stable IDs, callbacks, and an optional closesOnPress flag. They do not await returned promises. Leave a retry message open while the application runs the retry, then update or close it after a confirmed outcome. Do not set closesOnPress merely because the action starts recovery.
Use controlled open and onOpenChange when the application owns visibility. The component has no automatic expiry timer or notification queue. If the application adds either, keep important messages and actions available long enough to be read and used. Avoid stacking repeated reports of the same failure.
When an action or dismissal removes the focused element, move focus to a meaningful remaining control. Do not interpret a closed Banner as acknowledgement of every underlying event.
State the result first, then explain the consequence or next step. Prefer “Report uploaded” to “Success.” Avoid raw exception text when it does not help the person recover. Match urgency to the actual impact and avoid warning treatment for routine information.
Choose live behavior deliberately and test announcements with the application. A live region should not duplicate another message already announcing the same event. Do not move focus to routine feedback just to make it noticeable.
Keep actionable messages reachable with a keyboard. Use text as well as severity color and icon. Review narrow layouts and long action labels, including a meaningful dismiss label when multiple messages could be present.
Read Banner for status, action, and dismissal props. Use Forms for field errors rather than replacing them with a distant global message.