Component contracts compound

A renderer is only the visible part

Teams often call a piece of reusable markup a component. That is enough to reduce copy and paste, but it is not enough to create a dependable authoring system.

A website component needs to answer questions for several audiences at once:

• What job does this pattern solve?
• When should an author choose something else?
• Which content is required?
• Which semantic variants are valid?
• What accessibility requirements cannot be inferred automatically?
• Does the component add client or server behavior?
• How does it look with and without the consumer theme?
• Which public pages use it today?
• What tests protect its responsive and interaction contract?

Sights keeps those answers beside the renderer in one manifest-backed definition.

One source should produce every interface

The props schema becomes runtime validation, an exported JSON Schema, inferred TypeScript, generated agent documentation, and the data contract shown in the component viewer.

The authoring guidance becomes catalog search text and human-readable documentation. Examples become review routes and test fixtures. Runtime declarations become page capability output. A semantic thumbnail preset becomes the catalog's visual cue without introducing maintained screenshots.

This is less glamorous than a new animation. It is also what keeps the system from lying to its users six months later.

Complete components preserve the boundary

If authors receive only stacks, grids, columns, headings, and boxes, the page file becomes a low-level layout program. Responsive decisions, heading relationships, spacing, and content priority leak back into declarative data.

Sights keeps primitives in trusted implementation code. Page authors choose complete responsibilities such as hero, feature grid, FAQ, comparison table, showcase, or call to action.

That makes the component opinionated enough to test and the page flexible enough to tell a story.

Reuse should escalate slowly

Not every unique section belongs in the platform. A consumer can register a site-owned component through the same contract and prove it against one real need.

Only after several consumers need the same responsibility should the pattern move into Sights. By then, the prop vocabulary, responsive behavior, accessibility constraints, and useful variants are grounded in evidence rather than speculation.

This is how the catalog compounds without becoming a warehouse of nearly identical components.

Quality moves with the contract

When a shared component fixes a keyboard bug, image crop, heading relationship, narrow-screen order, or overflow issue, every site using that contract can benefit. The canonical demo proves the behavior across themes, examples, pages, and browser engines before the change travels.

That is the real economic value of a component system: not fewer files, but fewer solved problems becoming local again.