shadcn.io is not affiliated with official shadcn/ui
Reproduction Steps Report Contact Block for React Aria
A bug report on two overshoot cells: a severity segment, steps to reproduce you add and remove (up to six), expected and actual notes, one optional attachment, and a panel that ticks off what the report still needs.
Installation
Overview
A bug-report section for React with React Aria, laid out as two cells whose lines overshoot their corners. The first holds the report: a short title, a severity in a Segment Group (cosmetic, minor, major, blocker), the steps to reproduce as an ordered list of inputs with an "Add step" button (up to six, two to start) and a remove button on each row once there are more than two, "Expected" and "Actual" notes side by side (one over the other on a phone) and one optional attachment of up to two files. The second cell is a "What we need" panel that ticks off the title, two steps, a severity and both notes as they are filled in, keeps a count ("3 of 5 ready") and says what the chosen severity means. Submitting checks the report and focuses the first problem (the first empty step when the steps are short); a valid report turns into a confirmation in the same space. It's built from Segment Group, File Upload, Textarea, Input, Field, Guides, Shine Button and Button, with your theme's tokens for every colour. For bug trackers, support desks and open-source projects that want reproducible reports.
FAQ
How do the steps work?
Each step is its own input in an ordered list, named "Step 1", "Step 2" for a screen reader. "Add step" adds a row and moves focus into it, up to MAX_STEPS (six); once there are more than two, each row has a remove button, and removing one sends focus back to "Add step". A polite line says what changed ("Step 6 removed. 5 steps."). Every row has a stable id, so removing the middle one never mixes up the text.
What does the panel on the side do?
It lists the five things a report needs and fills each one in as the form meets it, with a count underneath. Each row carries "Done:" or "Needed:" for screen readers, and the count is spoken about 600 milliseconds after the last change instead of on every key. The severity line under the count changes with the chosen severity (all four wordings share one grid cell, so nothing moves).
Is the attachment really uploaded?
No. The file stays in the visitor's browser tab and only its name is listed; nothing is sent. A file that is not an image or a text log, or that is over 5 MB, or a third file, is refused with a polite line saying which and why; a drop that mixes good and refused files keeps the good ones. To make it real, send the files where submit waits and check them again on your server.
Where does the report go?
Nowhere yet. The submit waits 800 milliseconds as a stand-in for a request, then shows a confirmation that says plainly it was saved in the demo only. Replace the timer in submit with your tracker's API: title, steps, severity, expected, actual and files hold everything.