Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Toast Style Error Block for React

A panel whose body is a toast stage: error cards grouped by cause with a count, Retry and Retry all with a bounded outcome, cards that stay until dismissed, and a real toast raised through the block's own toaster.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Show a flaky connection as one problem, not a pile, with this toast style error panel for React with Base UI. It's the panel Pipeharbor, a data-pipeline tool, shows: a compact header over one framed panel on plus-marked corners made with Guides, whose body is a stage. The stage is a drawn runs table with the app's own bar on top, holding the one Shine Button, Sync now. At the stage's foot end the stack of error cards is drawn in place as a list named Notifications, with three fixed slots, one for each cause: the server can't be reached, the server is slow, a file was rejected. Sync now fails on a script, and a repeat of the same cause merges into its card with a count (x4) instead of piling up. Each card has Retry and Dismiss; Retry all runs a bounded outcome in which two causes recover and fold away and the rejected file stays failed with its reason. Each press also raises one real toast through the block's own toaster, which never times out. For any app that reports background failures.

FAQ

Are the failures and retries real?

No: they are a simulation. Sync now fails on a typed script (the server twice, a slow answer, a rejected file, then again) and each retry waits under a second and follows a typed outcome: the server and the slow answer recover, and the rejected file stays failed, because retrying doesn't change a bad file. Nothing is requested. In your app, group by a cause key from your errors and call your own retry from retryOne.

How does grouping by cause work?

Each cause has one slot and one card. A repeat of the same cause adds one to the card's count and keeps its place, so a hundred timeouts are still one card; a different cause takes its own slot. Slots are fixed in size, so a card that folds away leaves its room and nothing above it moves.

What is the real toast, and what is the drawn one?

The cards in the stage are drawn in place for the preview, in the shape of the catalog's toast. Each Sync now press also raises one real toast through this block's own toaster, in the corner of the page, that never times out because it has a Retry action; its Retry does what the card's does, and the card it came from folds away when it recovers. In your app keep the toaster and drop the drawn stack.

Why don't the cards go away by themselves?

Because an error needs an answer: a card that vanished after five seconds could be missed by someone who looks away, uses a screen reader or is slow to react. A card stays until it is dismissed or its retry recovers, and the polite status line says what changed ("Retried 3: 2 recovered, 1 still failing.").

How does it work with the keyboard?

Sync now first, then Retry all, then each card's Retry and Dismiss in order. When a card goes, focus moves to Sync now so it isn't lost. Retry buttons stay pressable while a retry runs and say so rather than disappearing; Start over is always there.

What changes on a phone?

Each card becomes two rows, the title and count above, the sentence and the buttons below, and the stack fills the width of the stage; the real toast sits at the foot of the screen.

  • Pro

    A dashboard window whose widgets fail on their own: orders that fail twice before loading, revenue from 3 of 5 sources with a details disclosure, a dismissible alert error, a recent errors list, and one Shine Button that retries what failed.

  • Pro

    A banner stack in an on-call console window: a critical banner that cannot be dismissed, a warning and an info banner that fold away, and a Dismissed row that restores them, in a window that never changes height.

  • Pro

    A debug-log viewer for an API monitoring tool, as a fixed-height app window: a Critical badge and copyable error id, a level filter with counts, eight log lines with the failing one marked, and a foot that copies, downloads and reports.

  • Pro

    A payments dashboard's charge page with a declined card: an error toast that never times out, a Retry that counts the attempts until the third turns it into Contact support, and the request id with a Copy button.

  • Pro

    A post scheduler's publishing queue with an Add a toast button: the toasts overlap in a stack of three, open into a list on hover or focus, and the rest wait their turn.

  • Pro

    A messaging app's thread with a message toast that carries a Reply action: it never times out, Reply takes it away and puts the sender in the composer with focus, and Receive a message raises the next of three, up to three at once.