Toast
Toast notifications display brief, auto-dismissing messages in the corner of the screen.
When to use
Do
- ✓Use toast for brief, non-blocking feedback about the result of an action — saving, deleting, publishing.
- ✓Use the success state to confirm that a user-initiated action completed successfully.
- ✓Use the error state to report a recoverable failure and guide the user to retry.
- ✓Use the warning state for time-sensitive information the user should act on soon.
- ✓Use the info state for neutral updates that improve context without requiring action.
- ✓Set duration to 0 for persistent toasts that must be manually dismissed.
Don't
- ✕Don't use toast for errors that block the user's workflow — use an inline notification or modal instead.
- ✕Don't show more than 3 toasts simultaneously; queue or batch messages when multiple actions fire at once.
- ✕Don't put interactive controls (links, buttons other than dismiss) inside a toast.
- ✕Don't use toast to replace form validation — validation errors must be inline.
- ✕Don't rely on toasts as the sole delivery mechanism for critical information — they auto-dismiss.
- ✕Don't render multiple <diwa-toast> elements in the same view; use one singleton per app.
Content guidelines
- Be concise — toast messages should fit on one line. Aim for fewer than 80 characters.
- Use sentence case — write messages as sentences with a capital first letter and no trailing period.
- Be specific — "Profile saved" is better than "Success". "Upload failed — file too large" is better than "Error".
- Avoid jargon — write for the end user, not the developer.
Placement
diwa-toast positions itself fixed at the bottom-right of the viewport with a z-index of 9999. Place one instance high in your component tree (e.g. in your root layout) so it is accessible from anywhere in the app.