Skip to main content
Back to Blog
data components architecture configuration

Named Data Sources

Swifty Team Mar 5, 2026 3 min read

In any page with multiple components, data flows between them. A record selected in a list informs a detail panel. A filter selection in one component narrows results in another. A parent record's ID scopes the sub-list below it.

Managing these data relationships implicitly — through position in the page hierarchy or convention — works until it doesn't. Pages become hard to understand, and changes can have unexpected side effects on components that were implicitly relying on inherited data.

Named data sources make data relationships explicit.

Declaring What a Component Provides

A component that loads data declares what it provides under a name. A record detail component loading a customer record declares that it provides a data source named "customer." Any component that needs the customer's data can reference it by that name, regardless of where it is in the page hierarchy.

The name is the contract. The component providing it and the component consuming it agree on the name; the platform handles the connection.

Declaring What a Component Consumes

A component that needs data declares what it consumes and from which named source. A sub-list component for customer orders declares that it consumes the "customer" source to get the customer ID for filtering.

If the named source isn't available on the page — if the consuming component is placed on a page without a customer detail component providing that source — the platform reports the missing dependency clearly. No silent failures, no confusing empty states.

Why Names Beat Implicit Hierarchy

Implicit data flow through page hierarchy works for simple pages. Deep nesting and complex layouts break it down. When a component three levels deep needs data from a component two levels up in a different branch, hierarchy-based flow can't express that relationship.

Named sources can. The provider and consumer reference each other by name, not by position. Page reorganization doesn't break data flow. Moving components in the layout doesn't sever connections.

Visible in the Builder

Named data sources are visible in the builder's configuration sidebar. When you select a component, its declared inputs and outputs appear in a "Data Connections" section. You can see what data it needs, what data it provides, and whether the connections are satisfied.

This makes page structure legible. Someone editing a page built by someone else can understand the data flow by reading the declared connections — no need to trace implicit inheritance chains.

A Foundation for Complex Dashboards

Named data sources are particularly valuable for dashboards that combine multiple independent data streams. A monitoring dashboard might have four named sources — metrics, alerts, deployments, and team status — each powering different components. The names keep the relationships clear and the page maintainable as it grows.

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.