shadcn.io is not affiliated with official shadcn/ui
Email First Sign In Login Block for React
An identifier-first sign-in for an invoicing app: one email field, a lookup against two typed accounts, then either the password step with the address kept as a badge or account creation with the address carried over.
Installation
Overview
Ask for the email first and decide what to ask next, with this email first login block for React with Base UI. It's the sign-in of Billfinch, an invoicing app: the page's side rails run the full height of the screen and one band crosses it between two rules, holding a centred column with the product's mark, a heading and a single Field with an Input for the email. Continue looks the address up in two typed accounts. A known address moves on to the password step, where the address stays above the field in a Badge beside a Back Button and focus lands on the Password Input; an unknown one turns the same card into account creation, asking only for a name and a password, with a line saying no account was found and the address carried over. The email step, the password step, account creation and the result all share one grid cell, so the page never changes height, and the Shine Button is the only colored control. It's built from Field, Input, Password Input, Badge, Button, Shine Button and Guides, with CSS transitions only. For any product where the account decides what a visitor is asked next.
FAQ
What stays in the page, and how do I wire the lookup?
The lookup knows two typed accounts, maya@billfinch.example and luis@billfinch.example, and waits 700 milliseconds, so every visitor gets the same answer and nothing is sent. Signing in and creating an account wait the same way, then show what happened in the card's own space, with a polite status message saying nothing was sent. In a product, post the address to your own endpoint where the code says so, keep the busy state until it answers, and branch on what it says: a password step, a redirect to single sign-on, a magic link, or sign-up.
Doesn't asking for the email first reveal which addresses have accounts?
It does, and that is the price of this flow: anyone can try addresses and see which go to the password step. Rate-limit the lookup per address and per client, answer in the same time whether or not the account exists, and ask for a challenge after repeated misses. If revealing it is not acceptable for your product, send every address to a step that can't be told apart, such as a sign-in link by email.
What does Back keep, and where does focus go?
Back returns to the email step with the address still in the field and focus on it. The password, the name and any problems are cleared, so nothing sensitive stays in the page. While you are on the password or sign-up step the address stays above the field in a badge, so it's always clear which account you are signing in to.
Why is the Continue button never disabled?
A disabled button can't say why, and keyboard users can't reach it. Pressing Continue with no address, or one that isn't a full address, marks the field invalid, writes one sentence under it and moves focus there; each step does the same for its own fields. Each field keeps a line for its problem even when there is none, so nothing moves when one appears.
How does the card keep its height between steps?
The steps and the result sit in one grid cell, and the ones not showing are invisible, out of the tab order and hidden from assistive technology, so a keyboard or screen reader user only meets the step in hand. The cell is as tall as the tallest step, account creation, all the time, which matters because the page is centered: anything that grew would move the heading too. With reduced motion the steps simply swap.
Will password managers fill each step?
The email is a real email field with autocomplete username, the password step asks for current-password and account creation for new-password, so a manager can offer the saved address on the first step, the password on the second and a new password on sign-up. Managers differ in how well they follow two-step sign-ins; if one of yours needs both fields on one screen to save a sign-in, keep the address in the second step as a hidden field.
Related
- Pro
Welcome Back Login
Account choosersA full-height returning-user sign-in for a reading tracker: a large initials avatar, Welcome back, Dara, a read-only address and one password field, with a swap to a different account at the same height.
- Pro
Multi Step Rail Login
Step by stepA three-step sign-in for a support desk: a vertical Steps rail at the start (Email, Password, Code) with what was given and an Edit button on each finished step, and the one panel of the step in hand at the end.
- @Pro
Create Account Handle Check Login
Sign-up and consentA sign-up page for a community forum in two columns of fields: a handle with an at sign that checks itself against a typed taken list and offers three tries as buttons, then the email, a password with an eight-character hint and Create account.
- Pro
Domain Routing Login
SSO and providersA sign-in page for workforce scheduling that reads the domain of your email and says how that company signs in: one required provider, a provider with a password option, a choice of two, or a password for a stranger.
- Pro
Passwordless Login
PasswordlessA full-height method picker for a podcast app: four hairline radio rows (email link, passkey, text code, authenticator app), a cell that says what happens next for the chosen way, and one button whose label follows the choice.
- Pro
Centered Sign In Login
Centered formA full-height sign-in page for a team chat app: the product's mark, Google and GitHub rows with lettermark tiles, an or rule, email and password checked on submit, and one Sign in button with a simulated wait and its result.