Our component design standard

Reusable components are how a site stays coherent as it grows.

Components should represent real patterns

We create components for things that repeat or have distinct behavior: navigation, footers, buttons, card systems, forms, schema helpers, content layouts, and other reusable interface structures. We do not break every three lines of markup into a component. Reuse should make the code clearer, not more fragmented.

Components should own their behavior

If a navigation component controls a menu, its accessibility state and interaction logic should live with that navigation system. The goal is to keep each part understandable in isolation.

Shared components protect consistency

A repeated call to action should look and behave the same across the site. Centralizing it reduces visual drift and prevents accessibility or responsive bugs from multiplying across copied implementations.

Props should stay understandable

We prefer explicit inputs over giant configuration objects that require documentation just to render a card. A component should tell the next developer what it needs.

The value is operational

Clients may never see the component tree, but they benefit from it. Changes become faster, regressions are easier to isolate, and a site can evolve without each page becoming its own independent design system.

Components are where repeated behavior becomes enforceable

The strongest reason to create a component is not that the markup appears twice. It is that the behavior or meaning should stay consistent. Navigation is a good example. Desktop links, mobile disclosure behavior, keyboard interaction, current-page state, and responsive styling all belong to one navigation system. If those rules are copied across pages, they will drift.

The same is true for galleries and dialogs. In our repos, a gallery component owns keyboard handling and cleanup for its active state, while a gated resource component owns the open state, Escape behavior, body-scroll locking, form state, and error handling. The page around those components does not need to understand their internal interaction lifecycle.

We keep data loading out of presentational components where practical

A route or server-side library generally loads and normalizes the content before handing it to the component tree. A location component receives a location model. A service component receives a service model. The component can focus on rendering a trustworthy object instead of reading files, parsing frontmatter, and inventing fallbacks while it paints the interface.

That boundary also makes components easier to test and reuse. The data source can evolve without forcing the visual component to understand where the data came from.

Reuse should not erase real differences

We do not try to build one mega-component that can render every section through a hundred props. That kind of abstraction is often harder to maintain than a few clear components. Shared behavior should be shared, but genuinely different page structures are allowed to remain different.

The useful question is whether two pieces of interface have the same responsibility. If they do, a shared component often makes sense. If they only look vaguely similar today, forcing them together can create a brittle API.

Component boundaries affect performance

A component that needs browser state can be a Client Component without forcing its entire parent page into the client bundle. This is a major reason we care about boundaries in Next.js. The gallery can hydrate while the article remains server rendered. The mobile menu can be interactive while the rest of the layout remains ordinary HTML.

That relationship is explained further in Server Components and Client Components. Component design is not only organization. In a server-first framework, it also determines how much work the browser inherits.