Sign Up
Sign Up
Section titled “Sign Up”Account creation with terms acceptance and social sign-up.
Preview
Section titled “Preview”Open the exact pattern in the real BeeUI Web Showcase. This is a Web runtime preview, not native-device evidence. The same source is available at apps/showcase/patterns/auth/screens/sign-up-screen.tsx.
Composition
Section titled “Composition”Principal public BeeUI exports used by this screen: AlertBanner, Button, Card, Checkbox, Field, Input, Link, PasswordInput, Text, VStack.
The pattern is a composition recipe rather than a new framework layer. Follow the linked component contracts for state, provider, platform and accessibility details.
State and callback contract
Section titled “State and callback contract”The screen is controlled through SignUpScreenProps. User intent crosses the application boundary through onAcceptedTermsChange, onAppleSignIn, onConfirmPasswordChange, onEmailChange, onGoogleSignIn, onNameChange, onPasswordChange, onSignIn, onSubmit; fetching, routing, persistence and side effects remain application-owned.
Common product states such as loading, success, empty, error, permission-like recovery, filtering/search/selection or pagination are represented only where the actual screen source exposes them. The pattern docs do not invent backend states that the fixture does not render.
Responsive contract
Section titled “Responsive contract”This pattern follows BeeUI’s mobile-first responsive contract: narrow-phone composition is the baseline; larger widths may reflow or promote navigation/layout according to BeeUI breakpoint tokens. Safe-area and scroll ownership stay explicit, and short-height/landscape/large-text constraints must be handled without viewport-level horizontal scrolling.
Accessibility
Section titled “Accessibility”The screen inherits the semantics, touch-target, focus/keyboard, RTL, large-text and reduced-motion contracts of its component composition. Use the Accessibility guide for evidence scope. A Web preview does not substitute for VoiceOver/TalkBack runtime evidence.
Application ownership boundary
Section titled “Application ownership boundary”Intentionally excluded: Account creation, validation rules, OAuth, and terms storage.
BeeUI does not take ownership of app routing, authentication/business rules, APIs/data fetching, persistence, form/state frameworks, chart frameworks or backend logic merely because a pattern visually composes those product concepts.
Source ownership
Section titled “Source ownership”Adapt the pattern by owning the screen source and, where useful, source-owning its BeeUI components through the repository-local Registry workflow. Before public CLI publication, use CLI & source ownership from a BeeUI checkout rather than a public npx command.