Toast

The Toast component provides a way to show live, time-sensitive feedback to users, which includes updates or changes to the system status. To display the Toast component use the ToastContainer along with the showToast function. The function accepts ToastOptions as an argument, allowing you to pass various configurations, and returns the corresponding toast id.

OverviewPropertiesUsage

Types

Toasts come in four types:

Default

• Use the default type for generic information that has neither a positive nor a negative meaning. For example, a notification about an automatic update during a process.
• Default Toasts close automatically.

Success

• Use the success type for positive feedback or to let users know that an action or process was successful. For example, when an access request is triggered and sent to an administrator.
• Success Toasts close automatically.

Warning

• Use the warning type to inform users about a potential issue or something that could cause a problem. For example, an unessential process that failed.
• Warning Toasts don't close automatically.

Critical

• Use the critical type for negative feedback or to let users know about issues that require immediate attention. For example, an essential action or process that failed.
• Critical Toasts don't close automatically.

Position

Align toasts at the bottom left of the screen by default. If the default position covers essential content in your app, alternative positions are available. However, use alternative positions rarely, as they're exceptions to the rule.

Toast vs. inline messages

Toast

• Use toasts for subtle feedback that should always be visible, regardless of where the user is in an app. The information doesn't need to be related to the user's current context.
• Always use toasts for temporary messages that shouldn't cause a significant disruption in the user's workflow.
• Avoid greeting users with toasts when they open an app or page. Instead, use inline messages to inform users about what has happened. For example, when warning users about scheduled system maintenance on a specific date.

Inline messages

• Use inline messages to communicate contextual information prominently. For example, at the beginning of a form, to warn the user about an impactful change.

Content guidelines

General

• The title should state the following action or most important information for the user. Keep the title to five words or fewer. Titles don't get periods.
• The body text should give the necessary details but be short and simple. Aim for a maximum of one sentence and put a period at the end.
• Use sentence case in both the title and the body text.

Message content

• Use the same word to refer to the same thing. Don't use different words for the same thing.
• If you add an action button in a toast, try to repeat the keyword from the title or body text in the button text. For example, if the title is Delete this notebook? the button text could be Delete notebook.
• When confirming the completion of an action, put the most meaningful word or action first. For example, Deleted message, not Message deleted.
• Don't add successfully or unsuccessfully to confirmation messages. For example, write Saved (not Saved successfully).
• For critical or warning messages, state the cause of the issue and suggest a potential action or give a support link.