Introduction
A Framer component is a reusable piece of design with one definition and many instances. Change the definition and every instance updates. Variants let one component hold several states, and properties let each instance differ without breaking that link.
Components are how a site stays consistent past its tenth page. They are also easy to overuse, which is the part nobody warns you about.
One Definition, Many Instances
The value is not reuse for its own sake, it is that a change happens once. A button used in forty places is forty edits without a component and one edit with it. That is the whole argument, and it only pays off on things that genuinely repeat.
Variants Are States, Properties Are Content
This is the distinction that keeps a component library sane. Variants describe how something looks in a given state: default, hover, active, error. Properties describe what differs per instance: the label, the icon, the link.
Use a variant | Use a property |
|---|---|
Hover, active and disabled states | Button label text |
Primary versus secondary styling | Which icon shows |
Open and closed for an accordion | The destination link |
Layout that changes shape entirely | Anything the CMS supplies |
Get this backwards and you end up with a component carrying thirty variants that differ only in text, which is unmanageable and slow to edit.
When Not to Make One
If something appears once, it is a layout, not a component. If it appears twice and will never appear again, it is still probably a layout. The overhead of a component is real: it adds indirection, and editing a one off through a component definition is slower than editing the thing itself.
The rule we use is three. At three occurrences the maintenance saving beats the overhead, and below that it usually does not.
Components and the CMS Are Different Tools
A common confusion. Components handle repeated design; the CMS handles repeated content. A card component defines how a card looks, and a collection supplies the forty different cards. You almost always want both, doing their own jobs.
Worth naming the other kind too: alongside native components built on the canvas, Framer supports code components written in React, which is the route when something needs behavior the canvas cannot express. Most sites need none, and the ones that do usually need one or two.
Before You Build a Library
Build components when the second and third use appears, not in advance. Libraries designed up front tends to include things nobody needed and miss the things everybody did, and every unused component is still something you maintain.
Components, the CMS and breakpoints are the three concepts everything else in Framer sits on. Understand those and most of the rest is detail.
