Native Solid 2 fork. Original documentation and designs © WorkOS; historical posts retain their original context.
Toast
Features
Automatically closes.
Pauses closing on hover, focus and window blur.
Supports hotkey to jump to toast viewport.
Supports closing via swipe gesture.
Exposes CSS variables for swipe gesture animations.
Can be controlled or uncontrolled.
Anatomy
Import the component.
API Reference
Provider
The provider that wraps your toasts and toast viewport. It usually wraps the application.
Viewport
The fixed area where toasts appear. Users can jump to the viewport by pressing a hotkey. It is up to you to ensure the discoverability of the hotkey for keyboard users.
Root
The toast that automatically closes. It should not be held open to acquire a user response.
Title
An optional title for the toast.
Description
The toast message.
Action
An action that is safe to ignore to ensure users are not expected to complete tasks with unexpected side effects as a result of a time limit.
When obtaining a user response is necessary, portal an AlertDialog styled as a toast into the viewport instead.
Close
A button that allows users to dismiss the toast before its duration has elapsed.
Examples
Custom hotkey
Override the default hotkey using the event.code value for each key from keycode.info.
Custom duration
Customise the duration of a toast to override the provider value.
Duplicate toasts
When a toast must appear every time a user clicks a button, use state to render multiple instances of the same toast (see below). Alternatively, you can abstract the parts to create your own imperative API.
Animating swipe gesture
Combine --radix-toast-swipe-move-[x|y] and --radix-toast-swipe-end-[x|y] CSS variables with data-swipe="[start|move|cancel|end]" attributes to animate a swipe to close gesture. Here's an example:
Accessibility
Adheres to the aria-live requirements.
Sensitivity
Control the sensitivity of the toast for screen readers using the type prop.
For toasts that are the result of a user action, choose foreground. Toasts generated from background tasks should use background.
Foreground
Foreground toasts are announced immediately. Assistive technologies may choose to clear previously queued messages when a foreground toast appears. Try to avoid stacking distinct foreground toasts at the same time.
Background
Background toasts are announced at the next graceful opportunity, for example, when the screen reader has finished reading its current sentence. They do not clear queued messages so overusing them can be perceived as a laggy user experience for screen reader users when used in response to a user interaction.
Alternative action
Use the altText prop on the Action to instruct an alternative way of actioning the toast to screen reader users.
You can direct the user to a permanent place in your application where they can action it or implement your own custom hotkey logic. If implementing the latter, use foreground type to announce immediately and increase the duration to give the user ample time.
Close icon button
When providing an icon (or font icon), remember to label it correctly for screen reader users.
Keyboard Interactions
Custom APIs
Abstract parts
Create your own API by abstracting the primitive parts into your own component.
Usage
Implementation
Imperative API
Create your own imperative API to allow toast duplication if preferred.