shadcn.io is not affiliated with official shadcn/ui
Error Feedback Form Block for React
A full-height error page for a document-export tool that asks what you were trying to do: quick-pick chips that start the message, a checked message and optional email, and a thank-you that replaces the form in place.
Installation
Overview
Turn an error page into a bug report, with this error feedback block for React with Base UI. It's the error screen of Foldmoor, a document-export tool: the page's two side rails run its full height, and one band crosses the screen between two rules with a plus mark where each meets a rail. The product's mark sits over the heading "That didn't work, and it's on us" and one sentence, then a form in a frame on plus-marked corners ruled by Guides. Four chips in a Toggle Group, Exporting, Saving, Signing in and Something else, start the message with "I was exporting a document and ", for the visitor to finish; a Field holds the Textarea that needs at least ten characters of their own words, another an optional email Input, and the Shine Button sends it, the only colored control. Pressing it checks both fields, writes each problem under its field and moves focus to the first; a good press shows a spinner for a moment, then a thank-you in the form's own space that repeats what was written, with a way to send another. The page never changes height. It's built from Toggle Group, Field, Textarea, Input, Shine Button, Button and Guides, with a CSS entrance only. For the error page of any app that wants to hear what went wrong.
FAQ
What happens when I send feedback, and what stays in the page?
Nothing leaves the page. Send feedback waits under a spinner for less than a second, then shows "Thanks, that helps" with the chip you chose, your words and the email, and a polite status says nothing was sent; Send another brings back an empty form and moves focus to the message. To wire it for real, post the chip, the message, the email and the error reference to your support inbox or issue tracker where the code says so, keep the busy state until it answers, and show its error under the field it concerns if it fails.
What do the chips do, and do they overwrite what I typed?
A chip puts a starting sentence in the message ("I was saving my changes and ") so the visitor only has to finish it. It never replaces words the visitor wrote: a chip fills the message only while it's empty or still holds just a starting sentence, so changing chips before typing swaps the sentence and changing them after leaves the message alone. Pressing the chosen chip again clears the choice. The starting words don't count toward the ten characters, so a message can't pass by choosing a chip and sending.
Why is the button never disabled, and what does it check?
A disabled button can't explain itself, and keyboard users can't reach it. Pressing Send feedback with an empty or too short message, or an email that isn't an address, writes one sentence under that field and moves focus to the first problem. The email is optional: empty is fine, a half-typed address isn't. Every field keeps a line for its problem even when there is none, so a problem never pushes the page.
Where does the error reference come from?
REFERENCE is a typed constant, so the block reads the same on the server and in every browser. In your app, generate one id per failure, log it with the stack trace and send it with the feedback, so a message can be matched to the failure. Showing it under the button tells the visitor it will travel with their note.
How does it look on a phone?
The chips scroll sideways inside their own row instead of wrapping, the form fills the width and Send feedback stays on the first screen, full width. The textarea keeps its height, so a long message never shoves the button down the page.
Is it usable with a keyboard and a screen reader?
The chips are a labelled group of toggle buttons: arrow keys move between them and Space or Enter presses one. Each field has a real label, its problem is tied to it and read out when focus lands there, and after sending, focus moves to the thank-you heading while a polite status says what happened. Pressed state is a filled chip and a word to assistive technology, never only a color.
Related
- Pro
500 Server Error
Server and outagesA full-height 500 page for an event-ticketing site: the heading, a copyable reference and time, a Try again that honestly keeps failing, and a framed figure of the request's path with the failed stop marked.
- Pro
Error Support Channels
Help and supportA full-height error page for a handmade-goods marketplace that sends you to a person: three channels with their real cost in time, and a composer whose heading and button follow the channel and that attaches the error details.
- Pro
Server Error Incident Card
Server and outagesA server-error panel for a studio-booking app: a card of what the page knows (error type, time, a copyable request id, retries) and what you can do, with a Retry that adds a typed retry and keeps failing.
- Pro
Error Debug Logs Window
In-app errorsA 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
Error Troubleshooting Steps
Help and supportA full-height error page for a video-call app that walks you through four fixes: a Try again that honestly keeps failing, ticked steps each with a why and a How, a four-part bar, and a Still stuck note that switches on when all four are ticked.
- Pro
Request Timeout Error
Server and outagesA full-height 408 page for a report generator: a request waterfall on a fixed time axis with a cut line at the wait you choose, a verdict that says whether the answer would have arrived, and a Retry that names the wait.