Composition

Compose through public parts

Compound components expose the regions that carry real semantic or visual responsibility. Use those parts directly rather than reaching into private markup.

import { Card, Grid } from "@flowstack-ui/brick";

<Grid.Root columns={2} gap="4">
  <Card.Root>
    <Card.Header>
      <Card.Title>Active projects</Card.Title>
      <Card.Description>Work currently in progress.</Card.Description>
    </Card.Header>
    <Card.Content>12 projects</Card.Content>
  </Card.Root>
  <Card.Root>
    <Card.Header>
      <Card.Title>Ready to publish</Card.Title>
    </Card.Header>
    <Card.Content>3 projects</Card.Content>
  </Card.Root>
</Grid.Root>

The Grid owns page arrangement. Each Card owns its internal anatomy. Your application supplies the real project data and destination behavior.

Let each layer keep its job

Brick owns finished controls and visual composition. Blocks may later own reusable page assemblies. Your application owns routes, data, permissions, persistence, analytics, and domain workflows.

Prefer natural layout

Use Stack, Grid, Container, Surface, and ordinary CSS for page composition. Avoid wrapping every region in a Card merely to create separation; hierarchy should begin with content, typography, and spacing.

A useful rule is to choose the lightest owner that can express the requirement:

• use a Brick component for a finished interface element;
• use layout primitives or CSS to arrange a page;
• keep business state and effects in application code; and
• extract a larger assembly only after its contract repeats.

Extract after repetition

A complete header or settings section becomes a block candidate only after more than one product proves its content, responsive behavior, accessibility, customization, and framework boundary.