Skip to main content

Patterns

Patterns are composed solutions to common interface challenges. They combine Canon components and tokens into reusable recipes that solve real problems.

Components vs Patterns

Components are atomic building blocks. Patterns are molecular compositions that solve specific user problems.

Components

  • Single responsibility
  • Stateless or minimal state
  • Context-agnostic
  • Building blocks

Button, TextField, Card, Spinner

Patterns

  • Composed solutions
  • Handle user flows
  • Context-aware
  • Complete experiences

FormLayout, LoadingSkeleton, ErrorBoundary

Available Patterns

Each pattern documents the problem it solves, shows implementation examples, and explains when to use it.

Forms

Input layouts, validation feedback, multi-step flows, and error states. Accessible form patterns that guide users through data entry.

Loading

Skeleton screens, spinners, progress indicators, and content placeholders. Patterns that communicate system status during async operations.

Error Handling

Error boundaries, inline errors, toast notifications, and recovery flows. Graceful degradation when things go wrong.

Planned

Empty States

Zero-data views, first-time user experiences, and call-to-action placeholders. Making "nothing" helpful.

Planned

Pattern Documentation Structure

Each pattern follows a consistent documentation format.

Problem

What user need does this pattern address? When should you reach for it?

Solution

Visual examples and interactive demos showing the pattern in action.

Implementation

Code examples using Canon components and tokens. Copy-paste ready.

Accessibility

Keyboard navigation, screen reader considerations, and reduced motion support.

Variants

Alternative approaches for different contexts or requirements.

Anti-patterns

Common mistakes to avoid and why they cause problems.

Pattern Philosophy

Every Canon pattern follows the Subtractive Triad.

DRY (Implementation)

Patterns unify repeated solutions. If you find yourself composing the same components the same way, it becomes a pattern.

Rams (Artifact)

Every pattern must earn its existence. If a pattern doesn't solve a real, recurring problem, it doesn't belong.

Heidegger (System)

Patterns serve the whole. They should feel invisible when used correctly, the infrastructure receding into the experience.

"Weniger, aber besser."

Less, but better. - Dieter Rams

Patterns reduce cognitive load by providing proven solutions. A well-designed pattern is one you never think about because it simply works.