shadcn.io is not affiliated with official shadcn/ui
Guest or Account Checkout Block for Radix UI
An email-first checkout step: a known address asks for its password, a new one offers guest checkout with an optional account switch, and the button, the fields and the checks follow the case without the panel changing height.
Installation
Overview
Ask for an email first and then do the right thing with it, with this guest-or-account checkout for React with Radix UI. A compact header from Foxcroft, a hardware shop, sits over a hairline frame with a plus mark on each corner. The first band is the order: three lines and a total worked out in whole cents. Below it one Input takes the email, and the panel looks the address up in a short typed list as you type. An address the shop knows turns the step into "Welcome back, Sam" with a Password Input and a quiet "Email me a sign-in link"; any other valid address offers to continue as a guest, with a Switch "Create an account after I pay" that reveals one password field and its one-line rule. The three cases share one cell, so the panel never changes height, and the only Shine Button changes its label with the case. A press checks the real rules, names each problem and moves focus to the first; a clean press replaces the step with its result. It's built from Input, Password Input, Switch, Field, Button, Shine Button and Guides, with a CSS entrance only. For any checkout that has to choose between a guest and an account.
FAQ
How does it know the address has an account?
In the demo it compares the address with a typed list in the file (ACCOUNTS: sam@example.com and jo@example.com), lower-cased and trimmed. In your app, call your own endpoint when the email field is left (not on every keystroke), and be careful what you reveal: many shops answer the same way for every address and send a link instead, so the form can't be used to find out who has an account. If you prefer that, keep the sign-in link as the main path and drop the password field.
What does it check before it continues?
The email must look like an email. For a known address the password must be the demo password, which is printed under the field (tin-hammer-42) so you can see both outcomes. For a guest who turns on the account switch, the new password needs ten or more characters and at least one number. Each problem has its own reserved line with an icon and words, appears when you leave the field or press the button, and clears as you fix it. The button is never disabled.
Why doesn't the panel move when the case changes?
The three cases (nothing yet, known, guest) are laid in one grid cell and the two not showing are hidden from sight and from the keyboard, so the cell is always as tall as the tallest. The password field that appears with the account switch is also always laid out, only unseen until the switch is on. The result replaces the whole step in the same cell, so finishing doesn't grow the page either.
Is the account really created after I pay?
No. The demo never creates an account, signs anyone in or sends a link: each result says so in words ("Signed in, in this demo", "An account would be created after you pay"). The switch starts off, because an account is something the visitor asks for, not something we assume. After a real payment you would create the account on your server from the email and the password chosen here.
How are the password fields set up?
The sign-in field uses autoComplete="current-password" and the new one autoComplete="new-password", so password managers offer the right thing, and each has the catalog's show and hide button. The demo password sits in a constant and is cleared from state once the step finishes. Never ship a password hint like that: it is there only so the demo can be tried.
What stays local in the demo, and how do I wire it up?
Everything. The lookup is a constant list, the wait is a 600 ms timer and every result is a line of text. To connect it, replace kindOf with your lookup, send the password to your sign-in endpoint, create the guest session or the account on your server, and show the server's refusal in the same problem slot the local checks use.