The distinction between a component and a pattern is the single most important concept in any design system, and most early-stage teams get it wrong for about a year.
A component is a single reusable piece with a small number of props — a Button, an Input, a Tag, an Avatar. It has a well-defined API. It doesn't know what screen it's on. You can drop it into fifty places and it will look and behave consistently in all of them.
A pattern is a recipe for how to assemble components into a specific screen — a Login screen, an Empty state, a Settings panel. It is not a library artefact. It is a documented convention. It lives in the docs, not in the code.
The mistake is trying to turn patterns into components. You can feel this when somebody proposes a <LoginScreen> component with fourteen props to toggle which fields appear. They're trying to save copy-paste cost by inventing a component that will never be reused exactly, and the component becomes unmaintainable approximately nine props in.
The rule I use: if you can describe the thing in one sentence and it takes fewer than six props, it's probably a component. If you need a paragraph and ten props, it's a pattern — document it, give it a name, but do not freeze it into code. The patterns change every three months. The components stay for years. Treating them differently is how the system survives its second quarter.
Sign in to leave a comment.