Skip to content

Form Message

Destructive form feedback (with muted HelperText variant) using polite live-region semantics.

import { FormMessage, HelperText } from '@beemvp/beeui-ui';

There is no documented deep/private source import. For source ownership from a BeeUI checkout:

Terminal window
pnpm beeui -- add form-message

Registry metadata: registry/registry.json.

  • Family exports: FormMessage HelperText

Exported types: FormMessageProps, HelperTextProps

The generated API inventory is mechanically joined to packages/ui/src/index.ts, Registry metadata, and the component reference contract. For behavior details and defaults, use the canonical component behavior catalog rather than copying TypeScript declarations into a second hand-maintained table.

Controlled/uncontrolled props, callbacks, disabled semantics, normalization/fail-safe behavior, and mount/unmount rules are defined by the public types and the canonical behavior catalog. The executable fixtures below are the source-grounded usage examples; consumers should not infer state ownership from DOM structure or another UI library.

  • No additional provider is required by this family. BeeUIProvider remains the recommended application root.
  • Peer/native dependencies visible to this Registry item: react, react-native
  • Registry dependency closure: core-cn, text, theme
  • Safe-area ownership remains explicit: shell surfaces touching system edges opt into SafeArea; components do not silently invent app-shell insets.
  • Web consumers load the BeeUI semantic theme CSS as documented in Web onboarding.

The same public family is exposed across the supported target matrix; meaningful platform differences remain governed by the compatibility contract.

  • Web: live browser/keyboard behavior is verified by Web-specific checks where applicable.
  • iOS / Android: package/export/native compile evidence is not described as device-runtime proof. Consult the compatibility and native-preview guides for the exact evidence class.
  • Platform-specific or experimental behavior is called out in the canonical component/compatibility docs rather than hidden behind a generic parity claim.

Use the Accessibility overview, RTL/localization, and Large text & zoom alongside this family. Roles/states, keyboard/focus behavior, announcements, Dynamic Type/Web zoom, RTL, and reduced-motion expectations remain component-specific; BeeUI does not claim universal accessibility certification from automated tests.

BeeUI components consume semantic tokens and support the current typed variant/density contracts. Use Theming and Density. className is an implementation escape hatch for source-owned/application work, not a cross-engine portability guarantee.

Open the matching Web runtime in Showcase. The Showcase link demonstrates Web behavior; use the native-preview guide for real simulator/emulator/device paths.

This frame loads the real BeeUI Web Showcase on demand; it is not a second docs-only implementation. It proves browser behavior only. Use native preview for iOS/Android simulator, emulator or device paths.

  • Family root / primary export: FormMessage
    • Public composition parts / helpers:
      • HelperText
    • Exported type surface:
      • FormMessageProps
      • HelperTextProps

The tree above is ordinary document structure so it remains readable with keyboard and assistive technology; it is derived from the real public export family rather than a canvas-only diagram.

The following is the exact typechecked runtime Showcase fixture selected for this live preview: apps/showcase/component-gallery/public-doc-fixtures.tsx. Runtime gallery/pattern sources are preferred over test harnesses, and the displayed source and executable source are the same file; there is no separately maintained demo snippet.

import {
Calendar,
Card,
FormMessage,
Label,
MetadataRow,
Section,
Text,
useBeeToken,
VisuallyHidden,
VStack,
} from '@beemvp/beeui-ui';
import * as React from 'react';
/**
* Small runtime surface for public families that are otherwise consumed only by
* tests, private composition internals, or generated docs. Keeping these here
* gives the public docs a real, typechecked Showcase source instead of falling
* back to test/mock files.
*/
export function PublicDocFixtures() {
const [date, setDate] = React.useState({ day: 3, month: 9, year: 2026 });
const primary = useBeeToken('colors.primary');
return (
<VStack gap="lg" testID="public-doc-fixtures">
<Card className="gap-4" padding="lg">
<Section
description="Public primitives that are normally embedded in larger application compositions."
title="Documentation runtime fixtures"
>
<VStack gap="sm">
<Label required>Project name</Label>
<FormMessage>Example validation message</FormMessage>
<MetadataRow
description="Read through useBeeToken from the active Uniwind theme."
label="colors.primary"
value={String(primary)}
/>
<Text>
Visible companion text for the assistive-only content rendered immediately after it.
</Text>
<VisuallyHidden>
<Text>Assistive-only VisuallyHidden fixture</Text>
</VisuallyHidden>
</VStack>
</Section>
</Card>
<Card className="gap-4" padding="lg">
<Section
description="Standalone controlled Calendar using the same public API consumed by date-picker compositions."
title="Calendar"
>
<Calendar onValueChange={setDate} value={date} />
</Section>
</Card>
</VStack>
);
}

Use the code block’s copy affordance to copy the exact fixture. For a smaller app-specific example, start from the public imports shown above and keep only the state your screen owns.

No component-specific limitation is curated here. Check Compatibility and the linked behavior contract for target-specific constraints.