Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Email First Sign In Login Block for React Aria

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.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Ask for the email first and decide what to ask next, with this email first login block for React with React Aria. 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.