shadcn.io is not affiliated with official shadcn/ui
Form Validation Error Block for Svelte
A panel for a request sent with problems: a table of what was found in two groups, must fix and check this, each row with what was typed, the rule and one fix control, and a Shine Button that warns once.
Installation
Overview
Show every problem at once, and fix it where it sits, with this form validation panel for Svelte with Ark UI. It's the panel Gaggleby, a group-travel sign-up, shows after a request was sent with problems: a compact header over one framed panel on plus-marked corners made with Guides. A native table lists what was found in two groups. Must fix holds the name that is empty, the phone with 7 of 10 digits and the terms that were not accepted; Check this holds an email domain one typo away from a known one and a departure that falls on a Sunday. Each row shows what was typed, the rule and one fix control: an inline Input (the phone is laid into a pattern as you type), a tick box, or a suggestion button worked out from the data that turns into Undo once used. Fixing a row marks it fixed in place, so nothing moves, and the counts follow. The Shine Button sends the request once no must-fix is open, and warns once about what is still worth checking. For any form that sends first and checks after.
FAQ
What does Send do, and what stays in the page?
Nothing is sent. With a must-fix open, the button says how many and moves focus to the first one; with only checks open, the first press warns and the second sends; with none open it waits a moment and says in a polite status line that the request was sent in this demo and went nowhere. Start over puts the original problems back. To make it real, post the values from send and map your server's field errors onto these rows.
What is the difference between must fix and check this?
A must-fix is something the request can't go without: the name, a ten-digit phone, the accepted terms. A check is something that is allowed but probably a mistake: a domain that looks like a typo (found by comparing it to a short list of known ones, one or two letters apart), or a Sunday departure. Checks never block, they only get one warning.
How are the suggestions worked out?
By small pure helpers over the typed data: the email suggestion is the known domain within two single-letter edits of the one typed, and the date suggestion is the next day when the typed one is a Sunday (the weekday is read from the ISO date in UTC). Using one changes the value and the button becomes Undo, which puts the original back.
Is the table accessible, and what happens on a phone?
It is a native table with a caption, column heads, a row head for each field and a group heading for each of the two groups; the fix controls are real inputs with names. Below the medium breakpoint each row becomes a card (the field and its state, what was typed, the rule, the fix) from the same markup, so a screen reader reads the same thing in both. The table's height stays put: a fixed row height and a reserved two-line rule mean fixing a row changes words, never positions.
How do the counts and the status stay in step?
The visible counts ("2 to fix, 2 to check") are worked out from the values on every render and are hidden from assistive technology; the single polite status line speaks when a row has just been fixed or has come back ("Phone fixed. 2 to fix, 2 to check."), not on every keystroke.
How is this different from an error summary with links?
An error summary lists problems and links to the fields. Here the problems are the interface: each row holds its own fix, so there is nothing to scroll back to. It also keeps what was typed in view beside the rule, which makes the reason for the problem plain.