Components

A component is a decision that agrees to repeat itself. When the same button appears forty times, it should be one button with forty instances — a single source of truth that carries change everywhere at once.

Componentizing is a judgment call, not a reflex. The right moment is when a pattern has proven itself: the same element, the same behavior, appearing across frames with only small variations. Extracting too early creates structure for things that never stabilize; extracting too late makes change expensive.

Design components as systems of properties, not fixed artifacts. The variation that survives — size, state, tone — becomes the component’s vocabulary. Every prop is a promise that the team can express that difference without forking the design.

Keep the component honest with its instances. A component that no longer represents what its instances need is a liability in costume. Rename, restructure, or retire it — the shared language must stay true.