Chapter 3: Components (1.C)

Exam topic 1.C: Build and manage reusable components for consistency and scalability.
Key terms: Component instances, component properties, slots, style variants, shared libraries.
Weight: 8% of the exam (about 4 questions)

Components (called Symbols in older Webflow) are how you stop repeating yourself. A developer will recognise the model from React or Vue: a component has a definition, the definition is used through instances, instances are configured with props, children can be injected through slots, and the component can be distributed through a library. Webflow builds the same architecture visually.

---

3.1 Definition vs. instance

• The component definition (often called the main component) holds the structure, classes and default content.
• An instance is a placement of that component on a page.
• Editing the definition (entering the component, e.g. by double-clicking an instance or choosing Edit component) updates every instance site-wide.
• Instances can only differ where the definition allows it, through properties, slots and variants. That limit is intentional. It’s what keeps a design system consistent.

Unlinking (detaching)

You can unlink an instance. It turns into ordinary elements that no longer receive updates from the definition. Use this rarely:

• ✅ When you’re intentionally forking a one-off design that will never match the system again.
• ❌ To make a small text or image change. That’s what properties are for.
• ❌ As a habit. Every unlinked copy is a place where future updates silently won’t arrive.

When should something become a component?

Make it a component when it is:

• repeated (navbar, footer, CTA banner, card, testimonial),
• meant to stay consistent (a pricing table, a legal disclaimer),
• or a composition you’ll reuse with different content (section layouts, feature rows).

Don’t turn everything into a component. A layout used once gets nothing from it, and too many near-identical components (Card, Card 2, Card New, Card Final) are a maintenance problem in their own right. Variants and properties exist to avoid that sprawl.

---

3.2 Component properties

Properties are the component’s public API: the things a page builder or content editor may change per instance.

Common property types

Property type	Bound to	Example
Text	A text element’s content	Card title, button label
Rich text	A Rich Text element	Testimonial body
Image	Image source (and alt text)	Card thumbnail, avatar
Link	A link’s URL/target	CTA destination
Visibility	Whether an element renders	Show/hide a badge, an eyebrow label or an icon
Variant	Which style variant the instance uses	Primary / secondary / dark
Others (e.g. video, number, alt text…)	Depends on element	—

Designing good properties (API design thinking)

• Name properties for the content editor, not the developer: “Button label”, not “Text 3”.
• Give sensible defaults. A newly dropped instance should look finished.
• Group related properties so the settings panel stays readable.
• Use Visibility properties instead of creating separate components for “card with badge” and “card without badge”.
• One property can drive several elements where the platform allows it (e.g. one image used in two places), which keeps the API small.
• Image properties should include alt text, so every instance can carry meaningful alternative text, or be marked decorative.

Properties + CMS

When a component instance sits inside a Collection List or on a Collection template page, its properties can be connected to CMS fields. That’s the scalable pattern for things like a blog card: one card component reused on the blog index, the related posts list and the homepage, with each instance’s title, image and link bound to the relevant Collection item. Change the card design once, and every list updates.

---

3.3 Slots

Properties change values. Slots change contents. A slot is a placeholder region inside a component where whoever uses an instance can drop other elements or components.

Think of React’s children:

<Section title="Features">
  {/* anything can go here */}
  <FeatureGrid />
</Section>

In Webflow, you’d build a Section shell component (padding, container, heading area, background) with a slot for the body. Each page fills the slot with whatever it needs (a feature grid, a testimonial carousel, a form) while the shell stays consistent and centrally editable.

Why slots matter for scalability

Before slots, people had to either:

• make the whole section a component, which locked its contents (too rigid), or
• copy and unlink the section on each page (no central updates).

Slots resolve that trade-off: fixed structure, flexible content.

Slot best practices

• Use slots for layout wrappers: sections, modals, cards with custom bodies, tab panels.
• Keep the styling of the shell in the component; let the slot contents bring their own styles.
• Nesting components in slots is normal: a Card slot containing a Button component.
• Don’t use a slot where a simple property would do. If only text changes, use a Text property.

---

3.4 Style variants

A variant is a named, predefined styling version of a component: Primary / Secondary / Ghost buttons, Light / Dark sections, Horizontal / Vertical cards. Instances choose a variant from a list instead of being restyled by hand.

Variants vs. combo classes vs. separate components

Need	Best tool
Same structure, different styling chosen per instance	Component variant
Small styling modifier of a class outside of a component	Combo class
Different structure and purpose	Separate component
Different values (text, image, link)	Properties

Variants beat letting builders add combo classes to each instance, because:

• the allowed options are explicit and limited, so nobody invents is-blue-ish,
• they’re discoverable in the instance settings,
• changes to a variant update every instance using it.

---

3.5 Nested components

Components can contain other components: a Pricing Card contains a Button, and a Navbar contains Nav Link components. This mirrors real component architecture:

• Atoms (button, tag, icon) → molecules (card, nav link) → organisms (navbar, pricing section).

Editing the Button definition updates buttons inside every card, navbar and section. To let instance users change a nested component’s content, expose the nested component’s properties through the parent component’s properties.

---

3.6 Shared libraries

A library lets you share components (and design tokens such as variables) across multiple sites in a Workspace:

1. Build the system in a source site (the library).
2. Publish/share it as a library.
3. Install the library in other sites in the Workspace.
4. When the source changes, it publishes an update, and consuming sites review and accept updates.

Things to understand:

• Components from a library are edited in the source site, not in the consuming site. That keeps one source of truth across a whole brand.
• Consuming sites choose when to accept updates, which gives you a controlled rollout.
• It’s how agencies and in-house teams keep the brand consistent across a marketing site, a docs site and campaign microsites.
• Library availability depends on your Workspace plan. Check the current plan details before you design a multi-site strategy around it.

Code components (developer note)

With DevLink, developers can work across both directions: export Webflow components as React code, and bring React code components into Webflow so designers can place them visually and configure their props. For the exam, focus on native components. In practice, DevLink is the bridge between a Webflow design system and a React app.

---

3.7 Components and accessibility

• A component’s accessibility is built once and inherited everywhere. Get landmarks (<nav>, <header>, <footer>), heading levels, button semantics and focus states right in the definition.
• Heading levels inside components are a common trap: a card hard-coded with an H3 might be wrong on a page where it should be an H2. Choose levels deliberately for where the component will be used. Where the platform allows it, make the tag configurable, or design for consistent placement.
• Expose alt text through image properties, and give link properties meaningful text (avoid “Learn more” ×20 without context).

---

3.8 Component architecture checklist

• ☐ Repeated UI is componentised; one-off layouts are not.
• ☐ Each component has a clear name and a small, well-named property API.
• ☐ Visibility properties instead of near-duplicate components.
• ☐ Variants for styling options; no ad-hoc per-instance class edits.
• ☐ Slots for layout shells with flexible contents.
• ☐ CMS-bound properties for cards used in Collection Lists.
• ☐ No unnecessary unlinked instances.
• ☐ Multi-site brands use a shared library edited in one source site.

---

Practice questions: Components

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Comment *

Name *

Email *

Website

Δ