An overview of everything the design system provides. Theme: plain. Language: English.
Screens
The screens here are examples to copy rather than components.
Signing in
Show one main way in, with the others underneath. Do not split sign-up from sign-in — one button that works for both is less to explain and less to get wrong.
A link in your email
One field and one button. Nothing to remember and nothing to steal. Rastrillo does this out of the box.
Repeat the address back. It is the only chance to notice a typo before waiting for an email that will never come.
<section rst-box>
<h1>Check your email</h1>
<p>We sent a link to <bdi>grace@example.com</bdi>.</p>
<p><a href="/signin">Use a different address</a></p>
</section>
A passkey
The fastest way in for someone who has one, and nothing to type. Offer a second way as well: people lose devices, and a passkey that will not work is a locked door.
<section rst-box>
<h1>Sign in</h1>
<button rst-btn="primary" type="button">Use a passkey</button>
<p><a href="/signin">Email me a link instead</a></p>
</section>
Google, Apple and the rest
We give you the buttons, drawn the way each company requires. We do not give you the sign-in itself — you wire that up to whichever provider you use.
<section rst-box>
<h1>Sign in</h1>
<form rst-form method="post" action="/auth/google"><button rst-btn type="submit">Continue with Google</button></form>
<form rst-form method="post" action="/auth/apple"><button rst-btn type="submit">Continue with Apple</button></form>
<p><a href="/signin">Email me a link instead</a></p>
</section>
Email and password
If you do use passwords, use the same one-way-in layout, and put a way to reset directly under the button rather than hiding it.
We do not recommend passwords
People reuse them, they leak, and you inherit the job of storing them safely. Use a link in your email plus a passkey, or passkeys on their own, or sign-in with an account people already have. The screen below is here because some products still need it, not because it is a good default.