Component Architecture

Boundaries drawn by responsibility, state ownership and reuse — plus the contract a component owes: inputs, events, slots, behaviour and accessibility.

Drawing Component Boundaries

Six forces decide where a component ends — responsibility, state ownership, composition, reuse, render cost and accessibility — and "this file is getting long" is not one of them.

Q · Where should one component end and the next begin, and which force is actually making that decision?

What a Component Owes Its Caller

Inputs, outputs, slots, behaviour and accessibility are all part of the API. The a11y half is the half that gets left implicit, and that is where components break.

Q · What exactly does a component promise, and which of those promises are written down in its type?

Composition and Slots

Children are the mechanism that stops a component growing a prop for every possible variation. Compound components and scoped slots are what you reach for when the frame needs to talk to the filling.

Q · When a component needs to vary, should the caller pass another prop or pass content?

Prop Drilling, Context and Global State

Three ways to get a value from where it lives to where it is needed. Each buys something and each charges for it, and none of them is the default answer.

Q · This value lives four levels up from where I need it. What is the honest cost of each way of getting it there?

Over-Componentization

Indirection with no behaviour: a component per div, props that only pass through, and a stack ten frames deep to render one button.

Q · When has splitting things up stopped helping, and what does the excess actually cost?

What a Component Costs to Render

Framework work and browser work are two different bills. Re-running a component is cheap; mutating the DOM, invalidating style and forcing layout are not — and most components are not your bottleneck.

Q · When a component re-renders, what does the framework do, what does the browser do, and which of the two is actually costing me?