Use toast messages to provide updates about a process. The ToastMessage
component extends Box.
Want to find out about the provider? Read ToastMessage.provider documentation
Import component
import { ToastMessage } from 'rimble-ui';
Examples
Different ways to use the ToastMessage
component.
Standard toast
For when you want to just provide a quick process update like a confirmation.
<ToastMessage message={"Transaction started"} />
<ToastMessage message={"0xAc0...e5A connected"} colorTheme={"dark"} my={3} />
Standard toast with subtitle
For when you want to provide more value through extra helpful information. Ask yourself when implementing your toast: is there anything else I could tell the user that would be useful?
Transaction complete
You have 4.20 ETH remaining
<ToastMessage
message={"Transaction complete"}
secondaryMessage={"You have 4.20 ETH remaining"}
my={3}
/>
Switched network
You are now on Rinkeby
<ToastMessage
message={"Switched network"}
secondaryMessage={"You are now on Rinkeby"}
colorTheme={"dark"}
my={3}
/>
Icon
When you want to reinforce your message with a visual.
<ToastMessage message={"Welcome to my dapp"} icon={"Mood"} my={3} />
<ToastMessage
message={"Welcome to my dapp"}
icon={"Mood"}
my={3}
colorTheme={"dark"}
/>
Link
When your Toast message has a link to support it. Note: this link should only take users to optional, supporting info.
Transaction started
Check on its progress using Etherscan
<ToastMessage
message={"Transaction started"}
secondaryMessage={"Check on its progress using Etherscan"}
my={3}
actionText={"Check"}
actionHref={"#!"}
/>
Write update here [Required]
Supporting information for update [Optional]
<ToastMessage
message={"Write update here [Required]"}
secondaryMessage={"Supporting information for update [Optional]"}
icon={"InfoOutline"}
my={3}
actionText={"Link"}
actionHref={"#!"}
colorTheme={"dark"}
/>
Process toasts
Ready-made messages to help users understand what's happening with a process they initiate, like a transaction.
Because they disappear, process toasts should be supported by other persistent UI elements so that a user can see the status of their transaction. Alternatively a ToastMessage is a safe bet if your dApp uses a sidechain or some other method of completing transactions in less than a minute.
Processing
Processing 0.00018 ETH payment
<ToastMessage.Processing my={3} message={"Processing 0.00018 ETH payment"} />
Success
ETH sent
You have 1.03 Ether (ETH) remaining
<ToastMessage.Success
my={3}
message={"ETH sent"}
secondaryMessage={"You have 1.03 Ether (ETH) remaining"}
/>
Failure
Payment failed
You don't have enough Ether (ETH)
<ToastMessage.Failure
my={3}
message={"Payment failed"}
secondaryMessage={"You don't have enough Ether (ETH)"}
actionText={"Buy ETH"}
actionHref={"#!"}
/>
Props
actionHref
string
(optional)
Sets URL for button
actionText
string
(optional)
Sets text for button
Allows ToastMessage to be closed by user
colorTheme
enum
(optional)
Sets background and text color
Allowed values: 'light' 'dark' .
Sets primary message text
Default value:
'Write update here [Required]'
secondaryMessage
string
(optional)
Sets secondary message text
Sets type of ToastMessage to display
Allowed values: 'default' 'success' 'failure' 'processing' .
Design guidelines
Use the ToastMessage
component for messages and actions that should be helpful but ultimately ignorable without any impact on what the user wants to get done.
When to use
Toast with a title
For when you want to just provide a quick process update like a confirmation
Example scenarios
Toast with a subtitle
For when you want to provide more value through extra helpful information. Ask yourself when implementing your toast: is there anything else I could tell the user that would be useful?
Example scenarios
Payment sent
You have 4.20 ETH remaining
Transaction pending...
This might take a few minutes
Transaction failed
You didn't have enough Ether
How it works
ToastMessage
component disappears automatically- Users can dismiss them manually
- They display one at a time, so if multiple messages are necessary, each one should appear after the previous message.
Best practices
Think about placement
Toasts should steer clear of navigational elements and important areas of the screen. Consider that the MetaMask browser extension could potentially hide your toast messages.
Use for non-critical information
Only use Toast messages for missable information that doesn't require a user's attention or acknowledgement.
Don't use Toast messages for critical information that directly impacts the success of completing a task. They dismiss automatically so information can be missed.
Switch to Rinkeby to start the transaction
For critical information, use Modal to bring that info to the user's attention.
Stick to one optional link
The link should support your update and must be optional. This might be to provide further information (like linking to Etherscan).
Transaction started
Check on its progress at Etherscan
Links must be optional and not critical to proceeding with/completing a user's task.
Connect to start this transaction
Content
Some best practices for writing ToastMessages
.
Keep things short
Keep the copy short, yet meaningful, to make it readable in the time the Toast is visible. If you can't shorten it consider other UI.
Longer copy is harder to read in the time before the ToastMessage disappears.
We've started your transaction
Processing messages
Keep them in the present tense and reference what's being processed to give the user reassurance that what they've initiated is happening. An ellipsis can help indicate that something's happening.
Using the past tense to describe something that is happening can be less clear when read at a glance.
Success messages
Describe what's happened. Ethereum actions can take a while to it makes sense to remind the user of the action that has succeeded.
Avoid generic 'Success!' messages. Vague comments are less helpful than ones that reference the task at hand.
Echo the language the user interacted with to initiate the action in the success message. So if the button copy was 'Send Ether':
If the action was labelled as 'Sending Ether', don't switch up the vocabulary. Consistency creates less confusion.
Remove terms like 'successfully' – they don't add anything if your message explains what's happened.
'Successfully' makes your message longer unnecessarily.
Transaction confirmed successfully
Failure messages
Note: it may be preferable to use alternative components like
Modal to bring a transaction failure to a user's attention, as they can't be missed and provide more space for explanation.
Explain the reason for failure, offer a suggestion of what to do next and use the action to help the user remedy the situation.
Transaction failed
You didn't have enough Ether
Don't just tell a user something has failed without providing a suggestion of what to do next.
Echo the language the user interacted with to initiate the action in the failure message. So if the button copy was 'Pay 0.13 Ether':
If the action was labelled as 'Paying Ether', don't switch up the vocabulary. Consistency creates less confusion.
- Modal – you may want to use this component for transaction failures as it could be considered a critical information