Skip to content

Profile Setup

Collect display name, username, bio, and photo for a new profile.

Open the exact pattern in the real BeeUI Web Showcase. This is a Web runtime preview, not native-device evidence.

This screen exposes a single default state.

The same source is available at apps/showcase/patterns/auth/screens/profile-setup-screen.tsx.

Principal public BeeUI exports used by this screen: AlertBanner, Avatar, Button, Card, Field, Input, Link, Textarea, 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.

The screen is controlled through ProfileSetupScreenProps. User intent crosses the application boundary through onBack, onBioChange, onChangePhoto, onDisplayNameChange, onSkip, onSubmit, onUsernameChange; fetching, routing, persistence and side effects remain application-owned.

// from apps/showcase/patterns/auth/screens/profile-setup-screen.tsx
export type ProfileSetupFieldErrors = {
bio?: string;
displayName?: string;
username?: string;
};
export type ProfileSetupScreenProps = {
avatarUri?: string;
bio?: string;
currentStep?: number;
disabled?: boolean;
displayName: string;
error?: string;
fieldErrors?: ProfileSetupFieldErrors;
loading?: boolean;
onBack?: () => void;
onBioChange?: (value: string) => void;
onChangePhoto?: () => void;
onDisplayNameChange: (value: string) => void;
onSkip?: () => void;
onSubmit: () => void;
onUsernameChange?: (value: string) => void;
totalSteps?: number;
username?: string;
};

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.

Read from the screen file and the 1 pattern-local file in its runtime import closure, direct and transitive: auth/screens/profile-setup-screen.tsx, auth/components/auth-shared.tsx. Every fact below is scoped to those files and to nothing else.

  • BeeUI layout primitives rendered: Box (auth/components/auth-shared.tsx), HStack (auth/components/auth-shared.tsx), KeyboardAwareScreen (auth/components/auth-shared.tsx), VStack (auth/components/auth-shared.tsx, auth/screens/profile-setup-screen.tsx).
  • Scroll ownership: no ScrollView, FlatList, SectionList or VirtualizedList element in auth/screens/profile-setup-screen.tsx, auth/components/auth-shared.tsx; scrolling is owned by the composed KeyboardAwareScreen, whose own page derives it.
  • Horizontal scrolling: no horizontal scroll container in auth/screens/profile-setup-screen.tsx, auth/components/auth-shared.tsx.
  • Width constraint: contentWidth="sm" (auth/components/auth-shared.tsx).
  • Breakpoint-prefixed utility classes: none in auth/screens/profile-setup-screen.tsx, auth/components/auth-shared.tsx.
  • Platform-prefixed utility classes: none in auth/screens/profile-setup-screen.tsx; auth/components/auth-shared.tsx, the branch taken when compact is true.
  • Platform branching: no Platform.OS or Platform.select call in auth/screens/profile-setup-screen.tsx, auth/components/auth-shared.tsx.
  • Viewport measurement: no useWindowDimensions, Dimensions.get or breakpoint hook in auth/screens/profile-setup-screen.tsx, auth/components/auth-shared.tsx.

BeeUI’s mobile-first responsive contract is the framework-level document; the list above states only what this screen’s own files declare, and says nothing about how the composed components behave internally.

Read from the screen file and the 1 pattern-local file in its runtime import closure, direct and transitive: auth/screens/profile-setup-screen.tsx, auth/components/auth-shared.tsx. Every fact below is scoped to those files and to nothing else.

  • Roles this screen sets itself: none set in auth/screens/profile-setup-screen.tsx, auth/components/auth-shared.tsx.
  • Accessibility states and properties it sets itself: accessibilityLabel (auth/components/auth-shared.tsx).
  • Semantics inherited from composed BeeUI families: AlertBanner, Avatar, Box, Button, Card, Field, HStack, Input, KeyboardAwareScreen, Link (auth/screens/profile-setup-screen.tsx, only when onBack is true; auth/screens/profile-setup-screen.tsx, only when onSkip is true), Progress, Separator, Text, Textarea (auth/screens/profile-setup-screen.tsx, only when onBioChange is true), VStack — each family’s own page derives the roles and states it sets; they are not restated here.

Touch-target size, focus order, announcements, RTL, large-text and reduced-motion behavior are not derived from this source — see the Accessibility guide for what is and is not covered by evidence. A Web preview does not substitute for VoiceOver/TalkBack runtime evidence.

Intentionally excluded: Username availability checks, image upload, and profile persistence.

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.

ProfileSetupScreen is Showcase source you copy, not a package export: it is not shipped from any @beemvp/beeui-* package, and the Registry CLI (pnpm beeui list / pnpm beeui add) does not carry pattern screens. Copy apps/showcase/patterns/auth/screens/profile-setup-screen.tsx into your app and adapt it directly. Only the individual BeeUI components it composes (linked above) are available for source ownership through the repository-local Registry workflow; see CLI & source ownership for both the published npx @beemvp/beeui-cli@next path and the repository-local checkout path.