shadcn.io is not affiliated with official shadcn/ui
Device Fit Check Contact Block for React
A habit-app beta form with a platform segment, an OS version select and a status line that sets the submit button's reason.
Installation
Overview
A device-fit form for React with Base UI, for Pocketloom. A short centred column, with no card. A Segment Group picks iOS, Android or Web, and a Select lists that platform's versions. A status band under the select reads Supported or Not yet, notify me, and the Shine Button follows it: Request the beta, or Notify me. The button stays enabled either way, and a line under it says which of those two the visitor is sending. A TestFlight switch is always on the form. On Android and web its note says it will be recorded for the iOS beta and doesn't change that build. Name and email follow. Submitting checks the fields, shows each problem under its control and moves focus to the first one. A valid request confirms in the same space. It's built from Field, Input, Segment Group, Select, Switch, Status, Guides, Shine Button and Button, with a CSS entrance on the header and your theme's tokens for every colour. For apps that need to know the device before they send a build.
FAQ
Where does the form send its data?
Nowhere yet. The submit handler waits 800 milliseconds, as a stand-in for a request, then shows the confirmation. Replace that timer in submit with your own call. details holds the name, email, platform, version and whether TestFlight is on. Show the confirmation when the request succeeds, and an error line in the form when it doesn't.
How does the status change the button?
Each version is marked supported or not. The newest iOS, Android and the current browser are supported. The oldest of each list is not. The band shows Supported or Not yet, notify me, plus the version name. The button reads Request the beta when the version is supported and Notify me when it isn't, and the line under the button is the reason the button describes. Neither choice is blocked: a notify request is a real submit. Changing platform selects the first version of that list.
How is the version select labelled?
The label OS version names the select, and focus can land on its trigger when the version is missing.
The select's trigger takes the id, and the label points to it with htmlFor.
What does the TestFlight switch do?
It's always on the form, so the column doesn't jump when the platform changes (both notes sit in one grid cell, the unused one invisible, so the height never changes). On iOS the note says the beta will be sent through TestFlight. On Android and web the note says it will be recorded for the iOS beta and doesn't change that build. The confirmation repeats the choice only when the switch is on.
What does the confirmation say, and who hears it?
It thanks the visitor by first name and repeats the platform and version they sent, and the email. A supported version is phrased as a request for a build. An unsupported one is phrased as a request to be told when that version is supported. It's a status region that takes focus when it appears, and "Send another request" brings back the form and puts focus on its heading.
How does it fit on a phone?
The three platforms share one row. Name and email stack below sm, and the submit button goes full width. The status band is a rule with plus marks under the select. The header fades up once on load. With reduced motion it simply appears. beta@pocketloom.example and +1 (555) 010-0155 are fictional. Replace EMAIL, PHONE, PHONE_HREF and HOURS with yours.
Related
- Pro
Request a Callback Contact
Calls and meetingsA callback request with a status band and a form that asks when to ring: as soon as possible, later today from a select of 15-minute times, or on a chosen day, with a time zone.
- Pro
Warranty Meter Contact
Repairs and claimsA warranty claim where the purchase date works out your cover on one line: a meter of the 24 months used, the month cover ends, and issue types that change with it.
- Pro
Talk to Sales Contact
Contact formsA talk-to-sales split for a scheduling platform: what happens next as three numbered steps and a band of contact details beside a form that checks itself, shows each problem under its field and confirms in place.
- Pro
Visitor Pass Contact
Visits and servicesA visitor pre-registration for an office building: pick a host from a directory, a weekday on a calendar and an arrival window, and get a check-in pass with a QR code.
- Pro
Document Checklist Contact
Finance and propertyA tax-return checklist as a card in a card: three ways of filing, eight documents with a tag that says which are needed, a bar of the needed ones ready and a switch to send the rest later.
- Pro
Photo Access Repair Contact
Repairs and claimsA repair request for a housing association: three photo slots with thumbnails, two access switches, a visit window, and a what-happens-next panel that rewrites itself as you choose.