Header Components: An Exception to Reusability

Why it exists

In design systems, the default goal is to make every component reusable. However, this principle creates significant friction when applied to the global site header, which is often the most complex, stateful, and context-specific component in an entire application.

The mental model

Treat the site header as a unique beast, an exception to the rule of maximum reuse. Instead of building a generic, configurable header component, build a specific, one-off composition. The value is in reusing the smaller pieces inside the header, not the container itself.

How it works

You intentionally "cut the cord" on reusability for the header container. This component is built specifically for its single purpose at the top of the page. The focus shifts from abstracting the container to ensuring the elements it contains are reusable. These smaller components, such as the logo, primary navigation links, search form, and utility buttons (like "Log In"), are built as flexible, context-agnostic patterns. The header then acts as a bespoke layout that orchestrates these reusable pieces, handling all the complex logic like responsive transformations and sticky positioning.

When to use it

Apply this "don't abstract the container" philosophy to the global site header, also known as the masthead. This is the component used exactly once per page, responsible for top-level branding and wayfinding. It's especially relevant when the header has complex responsive behaviors, like collapsing to an accordion on mobile and expanding to a mega menu on desktop.

When not to use it

This advice does not apply to the components within the header. The logo, search bar, and navigation patterns should be built for reuse. The principle of avoiding abstraction is specific to highly complex, single-use compositions. For most other components, like buttons, cards, or form inputs, aiming for maximum reuse is still the correct approach.

One canonical example

A header might combine a reusable <Logo>, <PrimaryNav>, and <SearchForm> component. The header's custom logic dictates that on screens narrower than 768px, the <PrimaryNav> renders as a hamburger-triggered drawer. On wider screens, it transforms into a visible mega menu. The header also manages its own position: sticky behavior. Trying to build a generic <Header> component that could handle all these specific requirements via props would result in a brittle, over-engineered mess.