Component boundaries follow responsibility, not pages

What it is

“Settings page header,” sliced by route, is not a reusable unit. When Profile needs the same chrome, you either duplicate the slice or excavate it from the page component. A responsibility-based boundary asks what the unit decides and what it emits: does it own navigation structure, does it fire a back event, does it own the title string. A page is an assembly of those units, not a component.

One page as one component writes the route into the boundary. When the route changes, the name and the implementation expire together.

Why it happens

A page slice encodes a node in the information architecture. A responsibility slice encodes a replaceable role. A header’s job is to show the current level’s title and offer back; a form section’s job is to collect a field group and report values. Their meeting on Settings is composition. Freezing the whole page as SettingsScreen treats the assembly as a part — a part that carries page-private spacing, analytics, and copy branches, that cannot be extracted, and that cannot be dropped onto another route.

A responsibility boundary is tested by what it refuses: the header must not know form validation; the form must not know which route it is on. What it can refuse is what makes the edge hard. A page-cut component knows a little of everything and can replace nothing on its own, and the variant table grows fake axes such as “settings edition / profile edition.”

Where it stops holding

A marketing landing that truly appears once, with no second assembly in sight, is cheaper as a whole-page component; do not pre-cut for reuse that does not exist. The application shell (root layout, route outlet) is itself a page-level responsibility; forcing it into a “generic header” can strip platform navigation conventions. Server-driven page templates versioned as pages keep the boundary at the template, not in client components. When ownership is already partitioned by page and the repo cannot move yet, draw responsibility files inside the page first, then extract to the library.

Applying it

• Write the component’s one-line brief as responsibilities (what it decides, what it emits) with no route name and no page name.
• When a second place needs the same UI, extract the responsibility unit. Do not grow the first page component into a giant with variant="profile".
• Keep page files as composition roots: import responsibility components and wire them; they must not author visual variants.
• How to check: reuse the same header on a new route. The page file changes assembly only; the header file is untouched. A branch that reads “if on Settings…” inside the header means the boundary is still a page cut.

Related

• Same group: R1.02.1 Variants must cover combinations that actually ship · R1.02.2 A combinatorial explosion of variants signals the wrong abstraction
• Nearby: R1.11 Component composability · R1.17 Over-generic component abstraction
• Search terms: responsibility-based component boundary · page slice · composition root