shadcn.io is not affiliated with official shadcn/ui
QR Code Login Block for Radix UI
A reverse-split sign-in for a TV app: a real QR code of a typed pairing link first on the screen, three numbered steps that tick off, a button that plays the phone scan and approval, Refresh code and a signed-in result.
Installation
Overview
Sign in a screen with no keyboard, with this QR code login block for React with Radix UI. It's the sign-in page of Screenlark, a TV streaming service, as a reverse split: the steps are first in the page and the code is first on the screen. The cell at the start holds a real QR Code of a typed pairing link in a framed tile, with the same code in words below for anyone who can't scan; behind its divider, which meets the band's two rules at a plus mark, are the heading and three numbered steps that tick off as the pairing moves. One button follows the state, the Shine Button "Simulate a scan (demo)" and then "Approve on the phone (demo)", and it is the only colored control. "Refresh code" cycles three typed links and retires any scan, "Use a password instead" is the way out, and confirming swaps in "You're signed in" in the same space. On a phone the code sits under the steps. It's built from QR Code, Button, Shine Button and Guides, with a CSS entrance only. For TV, console and kiosk apps where typing is the worst part.
FAQ
What stays in the page, and how would a real pairing work?
Everything: the code is a QR code of a typed link, and the two demo buttons play what the phone does, so nothing is scanned, sent or signed in. In a product, the screen asks your server for a short-lived pairing code and shows it as a QR code, then waits for it (by polling or a socket). The phone app scans it, the person confirms there, and the server tells the waiting screen to finish the sign-in with a session for that account.
What are the states, and what does Refresh code do?
The pairing is waiting for a scan, scanned and waiting for the phone's confirmation, or confirmed. Scanning dims the code and puts a tick over it; confirming swaps in the result. Refresh code moves on to the next of three typed links and says the old one no longer works, even when it had been scanned, which is the real rule: a code that is shown once works once. A new code returns the page to waiting.
What if someone can't scan the code?
The same pairing code is printed in words under the QR code, with the address to enter it at, so a person with no camera, or a screen too far away to scan, can type it on their phone instead. The QR code itself has a text name that includes the code. The password route stays one link away for anyone with no phone to hand.
Why does the phone have to confirm after scanning?
Scanning alone would let anyone who photographs a code on a screen sign in as its owner. Making the person confirm on their own device, ideally with a screen lock or a biometric, and showing them which screen they are linking, keeps the approval deliberate. The demo shows the two moments as two presses for that reason.