shadcn.io is not affiliated with official shadcn/ui
Welcome Back Login Block for Solid
A 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.
Installation
Overview
Greet the person who was here last, with this welcome back login block for Solid with Ark UI. It's the returning-user sign-in of Bookwren, a reading tracker: the page's side rails run the full height of the screen and one band crosses it between two rules, holding a centred column. A large Avatar shows Dara's initials over "Welcome back, Dara" and one sentence. A Field holds her address in a read-only Input, a second holds the Password Input with its show and hide toggle and a "Forgot password?" link, and the Shine Button signs in, the only colored control. "Not you? Use a different account" swaps the state in place: the avatar becomes a neutral person glyph, the heading and the sentence change, the address field opens up empty, and "Use Dara's account instead" brings her back, with nothing resizing either way. It's built from Avatar, Field, Input, Password Input, Button, Shine Button and Guides, with a CSS entrance only. For reading, music and any app people come back to daily.
FAQ
What stays in the page, and where does the remembered account come from?
The remembered account (Dara Nwosu, her address and her initials) is a typed constant, so the page shows the same thing to everyone and remembers nothing. Sign-in waits under a spinner for less than a second, then shows "You're signed in" and a polite status message says nothing was sent. In a product, keep the address, the display name and optionally an avatar URL of the last account that signed in on this browser in a cookie or in local storage, never the password or a token, read it when the page renders, and fall back to the plain email form when there isn't one. Post the form to your auth endpoint where the code says so.
What exactly changes when I press Not you?
Four things change, in place and at the same height: the avatar shows a person glyph instead of the initials, the heading reads "Sign in to Bookwren", the sentence asks for the email and password of the account you read with, and the address field stops being read-only and empties. Focus moves to that field, a polite message says what happened, and any problem on show is cleared. "Use Dara's account instead" reverses it and puts focus on the password.
Why is the address a read-only field and not plain text?
Password managers fill a sign-in by pairing the password with a username field, so the address stays a real field with autocomplete="username". It is read-only, not disabled, so it keeps its place in the tab order, is read out with its label and is still sent with the form. Its tint follows the theme, and it becomes an ordinary editable field when you switch account.
Is it safe to greet someone by name on a shared computer?
It is a convenience with a cost: anyone at that browser sees the name and the address. Offer it only after a visitor chose to be remembered, expire it with the session policy of your product, and keep the "Not you?" button where people can see it, as here. A password manager's fill still needs the password; the page never shows it.
Why is the Sign in button never disabled?
A disabled button can't explain itself, and keyboard users can't reach it. Pressing Sign in with no password (or, for another account, with no or a malformed email) marks those fields invalid, writes one sentence under each and moves focus to the first. Typing clears that field's problem, and each field keeps a line for its problem even when there is none, so nothing moves.