Brickv0.1.12
Appearance
Navigation & layoutBrick 0.1.12

Appearance

Appearance applies an explicit light, dark, or inherited semantic-token scope to one native or existing Brick host. It adds no paint, spacing, state, persistence, or required client provider.

Live example

Built from the published package

Interactive

Night review

One existing host owns this explicit dark appearance.

Choose with confidence

Know when Appearance is the right part

Use it when

Use Appearance when one region intentionally differs from its ancestor, when an existing component such as App Bar or Tabs should own the boundary, or when portalled visual roots must reproduce a local scope.

Choose another path when

Do not use it for document preference persistence, theme generation, or visual surface paint. Applications and framework adapters own preference and pre-paint policy; Surface owns neutral paint.

Installation and imports

tsx
import { Appearance } from "@flowstack-ui/brick/appearance";
import "@flowstack-ui/brick/styles.css";

For modular CSS, load @flowstack-ui/brick/styles/core.css once, then @flowstack-ui/brick/styles/appearance.css plus the modular styles for every component composed inside it.

Exports are Appearance, AppearanceProps, and AppearanceValue.

Quick start

tsx
<Appearance value="dark">
  <AppBar.Root>...</AppBar.Root>
</Appearance>

Visual recipes and states

Appearance has no component recipe or state. It applies data-brick-appearance; the complete token stylesheet assigns color-scheme and semantic values. Themes must supply complete assignments for every appearance they support.

Examples

tsx
<Appearance value="dark">
  <section>
    <Appearance value="light">
      <Surface>Light content inside a dark section</Surface>
    </Appearance>
  </section>
</Appearance>
Public contract

API

Start with the public parts and root options below. Components with multiple parts separate each area into its own named subsection.

PropValuesDefault
valuelight, dark, inheritinherit

The direct child must accept DOM props and a ref. Strings, Fragments, and multiple direct children are invalid. If the boundary needs semantic markup, author that element explicitly as the child.

Shared responsibility

Accessibility

Appearance adds no role, accessible name, focus behavior, or client state. Choose valid host semantics. The output is deterministic during SSR and hydration; applications that persist a root preference must apply it before paint.

Responsive behavior

Appearance has no breakpoint behavior. The existing child host keeps its responsive contract unchanged.

Stable visual contract

Styling and tokens

Customization

Use a complete theme assignment at explicit light and dark selectors. Put native attributes, events, class, and style on the child host. Do not set component colors on Appearance or use it as another theme-value authority.

Tokens and CSS hooks

Stable hooks are .brick-appearance and data-brick-appearance. Appearance publishes no component tokens and preserves the child's existing slot.

Advanced reference

Open these details only when you need to inspect DOM ownership, native forwarding, or lower-level composition.

Maintainer resources

Tests, playground evidence, source notes, and release history remain available without crowding the plug-and-play guide.
Source docsChangelogPlayground