Reusable Bricks Components Without the Bloat

Bricks components turn repeating sections into editable instances. Build the eyebrow, metric card, FAQ item, and CTA once — then swap text and icons per page. Done well, components are how a nine-service silo site stays consistent without copy-pasting markup into oblivion.

Done poorly, components become dumping grounds for page-specific marketing claims, one-off spacing hacks, and props nobody understands. This article covers when to componentize, which props to expose, and how to keep masters generic enough that new pages stay fast to assemble.

What belongs in a component

Componentize structure that repeats with different content. If two sections share layout, spacing, and interaction — and only copy or icons change — you have a component candidate.

• Same structure, different copy
• Shared hover and focus behavior
• Icons exposed as properties
• Spacing already tokenized
• Used on three or more templates, or clearly about to be

// Mental model for component props
$faq_item = [
  'question' => 'How long does a rebuild take?',
  'answer' => 'Depends on template count and content readiness.',
  'icon' => 'i-help',
];

Write that mental model down. Teams that skip it invent props ad hoc until the component settings panel looks like a second page builder.

What should stay as a page section

Unique heroes with custom compositions, experimental campaign layouts, and one-off editorial features should stay local. Forcing uniqueness into a component creates a prop explosion and a master nobody wants to open.

Also avoid componentizing too early. Build the section twice. On the third use, extract. Premature components encode the wrong abstraction and force awkward props to cover edge cases that should have been separate sections.

Props with clear ownership

Expose text, links, icons, and optional visibility flags. Do not expose raw CSS values as props if those values should come from the design system. Editors should change the question, not the border radius.

Naming props

Use the same language as your content model. question and answer beat text_1 and text_2. For CTAs, prefer label and url. Keep boolean props negative-rare: show_icon is clearer than hide_icon=false defaults buried in instances.

Group props in the order editors scan the visual component: eyebrow, title, body, CTA, media. Matching visual order to panel order reduces mistakes during content entry.

Anti-pattern: marketing claims in the master

Do not bake page-specific claims into the component definition. Keep defaults generic; override properties on the instance. A FAQ component whose default answer mentions a particular migration package will leak that copy onto unrelated pages.

/* Component root stays structural */
.faq-item {
  border-bottom: 1px solid var(--border-muted);
  padding-block: var(--space-md);
}
.faq-item__trigger {
  display: flex;
  justify-content: space-between;
  gap: var(--space-md);
}

Nestables inside components

Components can contain nestable structure. Keep depth shallow enough that overriding content stays obvious in the Bricks panel. Deep trees with many locked elements train editors to duplicate the whole page instead of editing the instance.

Animated icons that need keyframes may stay as small inline SVG inside the component. Static icons can use the Icon element pointing at shared SVG assets. Mixing both without a rule creates inconsistent stroke weights across the site.

Versioning and change control

Changing a component master updates every instance. That is the point — and the risk. For visual changes, review two or three consumer pages before and after. For content model changes (renaming props), plan a migration pass so empty props do not silently blank sections.

Document which pages own which components in your template map. When a component is retired, replace instances deliberately; do not leave orphans that break when the master is deleted.

Components and CSS chunks

Pair components with shared class names that your child theme already styles. The component should not need a page-scoped CSS blob. If you find yourself pasting large _cssCustom rules onto a component, stop and move those rules into the proper stylesheet chunk.

Visual parity comes from applying the correct shared class, not from !important override layers. Components that fight the design system become the reason new builders invent yet another global class.

Reusable components are how Bricks sites scale. Treat them as productized UI, not as a convenience clone button. Your future service pages will either thank you or inherit your shortcuts.

A practical extraction pass

When you finally extract a component, do it on a branch or staging copy first. Replace the original sections with instances, then click through every consumer page. Confirm prop defaults do not leak staging placeholder copy into production. Ten minutes of verification here prevents a week of mysterious wrong CTAs.