shadcn.io is not affiliated with official shadcn/ui
Linked Accounts Account Block for React
When a provider's email is not yours: a table of what each provider returned, a choice under each mismatch to add it as a second email or keep it separate, and a count of sign-ins that would make a new account.
Installation
Overview
Settle what a social sign-in should do when the provider returns a different address, with this email reconciliation panel for React with Base UI. A compact header holds the title and one sentence. Inside a hairline frame with a plus mark on each corner, a native table lists the providers that returned an address: the provider with a neutral lettermark tile, the address it gave, whether the provider says it has verified it and where signing in with it would lead, this account or a new one. Under each address that does not match this account, a pair of radio cards offers Add it as a second email or Keep it separate, each saying what it means, and an address the provider has not verified can only be kept separate. A line over the table counts the consequence ("2 of 3 would sign in to a new account") and follows every choice. The foot's one Shine Button, Apply, stays quiet until something changes, writes the choices in the page and says so, and Button Discard puts them back. It's built from Badge, Button, Shine Button and Guides, with native radios and a native table and a CSS entrance only. On a phone each provider becomes a card. For account settings, a social sign-in flow or any app that merges identities.
FAQ
How do I fill it with my own providers?
Edit PROVIDERS and ACCOUNT at the top. Each provider has an id, a two-letter mark for its neutral tile, a name, the email it returned and whether it is verified at the provider; ACCOUNT is the address this account was made with. A provider whose address equals ACCOUNT needs no choice, and every other one gets the radio cards, starting from the safe answer in START (keep it separate). The header count, the Signs in to column and the status line are all worked out from the choices, so they cannot disagree with the table.
What stays local, and how do I make it real?
Choosing, Apply and Discard only change this page's state: Apply says "Done in this demo. Nothing was sent." and no address is added to any account and no provider is contacted. To wire it, send the decisions in apply to your server, which should add the provider's address to the account only when the provider says it is verified, and load the returned addresses into PROVIDERS from your own link records.
Why can't an unverified address be added?
If an address that a provider has not verified could be attached to an account, anyone who typed someone else's address at that provider could take over the matching account. So that card is disabled with the reason in text, the choice stays on Keep it separate, and the account count says that signing in with it would create a new account. A provider that verifies the address makes both cards available.
How do the choices work with a keyboard?
Each pair is a native radio group named for its provider, so Tab reaches the checked card and the arrow keys move between the two, with the same ring on every library. A disabled card is skipped. The radio's name is its title and its sentence is its description. The cards are the radios' labels, so clicking anywhere on one picks it.
Is the table accessible?
It is a real table with a caption, column headers with scope, and a row header for each provider. The tiles are hidden from assistive technology because the name is always beside them, and the badges say their state in words. On a phone the head row is kept for screen readers and every cell carries its own label, so each card reads the same. One polite status line reports Apply, Discard and an empty press.
Related
- Pro
Connected Accounts Account
Connected appsThe sign-in providers linked to an account: each with its address, link date and use history, an Unlink that asks first and refuses on the only way in, an Undo line and quiet buttons to link more.
- Pro
Login Providers Account
Sign-in methodsGo passwordless safely: the sign-in methods ranked by strength as a ladder, the four things that must hold first, and one button that turns the password off only when they all do.
- Pro
Third-Party Apps Account
Connected appsOAuth grants as a table: each app with its access level, grant date and last use, unused apps pinned to the top, scopes in plain words, a Revoke that can be undone and a bulk revoke that asks first.
- Pro
OAuth Consent Login
Sign-up and consentA consent screen for a calendar when a scheduling app asks for access: two required permissions shown locked, two optional ones you can untick, a button that counts what it grants and a scope details disclosure.
- Pro
A panel of four sign-in methods (Password, Google, GitHub, X) with Connect and Disconnect that refuses to remove the last one, an alert dialog and Undo for the others, and a choice of which shows first.
- Pro
Merge Two Accounts Account
Connected appsA merge in three steps: the other account's email and code, the two accounts side by side with what moves, what is lost and three choices, and a confirm that closes the other account behind an alert dialog.