Skip to main content
Back to Blog
components reusability builder consistency

Component References: Define Once, Use Everywhere

Swifty Team Feb 28, 2026 3 min read

Copy-paste is the enemy of maintainability. In any system where components can be placed on multiple pages, the temptation is to configure a component once and duplicate it wherever else it's needed. The duplication problem only becomes visible later — when something needs to change, and the change needs to be applied to every copy individually.

Component references solve this. Define a component configuration once, name it, and reference it from any page. One definition, many instances, maintained in one place.

Named Component Definitions

A component reference starts with a named definition. Instead of configuring a data table directly on a page, you create a named component definition — "Recent Orders Table," "Active Projects List" — with all its configuration: columns, filters, sorting, actions.

That definition lives in the component library. Any page in the application can reference it by name.

Consistent Across Pages

When the same data table appears on a dashboard, a detail sidebar, and a standalone page, all three instances show the same configuration. The appearance is consistent. The behavior is consistent. Users interacting with "Recent Orders" know what to expect, regardless of which page they encounter it on.

This consistency has real value. Users build mental models of how components behave. Inconsistent configurations of the same logical component break those models and require re-learning.

Update Once, Apply Everywhere

When you modify a referenced component definition — add a column, change a filter, adjust the row count — the change applies to every page that references it. There's no need to find and update each use. The definition is the single source of truth.

This makes maintaining shared components dramatically simpler. A correction to a column label, a change to default sorting, a new action button — one edit propagates everywhere.

Local Overrides When Needed

Reference behavior is the default, but individual instances can override specific settings. A referenced table component might display 10 rows per page by default, but a particular page might need to show 5 to fit its layout. The override applies locally without breaking the shared definition.

Overrides are narrow by design. They affect only the specified settings; everything else continues to follow the shared definition.

Composing Larger Structures

Component references compose naturally. A dashboard layout defined once can be referenced on multiple pages. Each reference shows the same layout with the same components. Updating the dashboard layout definition updates all pages that use it.

This extends the principle of reusability from individual components to entire page sections — a meaningful capability for teams maintaining applications with many similar pages.

Related posts

Composed Data Sources

Chain and relate data sources for rich dashboards — compose complex data views from simpler sources without writing code.

Computed Expressions

Transform data with template expressions and built-in functions — format, combine, and derive values from your data without code.

Cross-Source Data Joins

Combine data from multiple sources in one view — join records from your database with data from external services using a shared key.