Registry components

​

What are registry components?

Registry components are registered UI building blocks the Visual Registry uses to render pages. Each component knows how to display a slice of Context Registry data — or capture new data back into it. Pages do not hard-code every screen from scratch. They compose components: an entity list here, a hero banner there, an add-instance button in the toolbar.

​

Component categories

Components fall into a few practical families:

​

Data display — lists and timelines

Show structured context in scannable formats: These pull from query configs tied to entity types and context types.

​

Layout — page chrome

Marketing and shell sections that frame content: Layout components often use static or bound content rather than entity queries.

​

Actions — add and enrich

Interactive components that write to the registry: These connect to ingest and update flows in the Context Registry — the same operations you configure under Context operations.

​

Entity list cells

Lists use specialized cell renderers for common field types — person names, contact info, tags, dates, and plain text — so columns look right without custom code per page.

​

Page-attached vs. standalone components

Components can be:

• Page-attached — belong to a specific registry page subscription (e.g. the people list on /p/people-list).
• Standalone — scoped to your organization or workspace for reuse across surfaces.

Page builders assign components to surface keys — named slots like main, toolbar, or hero — so render configs know where each block appears.

​

Component builder

Component builder test (under Intelligent Registries → Interface) is where your team previews and iterates on component configurations before they ship on production pages. Use it to validate layout, empty states, and query bindings.

​

Agents and components

Several components embed agent chat for guided data entry — add context and add instance flows often use conversational panels where an agent extracts structured values into the schema defined by your context types. That is the same intelligence layer Agents use elsewhere, specialized for registry capture.

​

How components connect to Tracks

Components surface registry instances. Tracks run processes on those instances. A page might let users browse candidates; a track moves each candidate through hiring checkpoints — both reference the same people entity type from the Context Registry. Next: Glossary — quick term lookup. If you would like something unique to your business or have a unique issue, use XSpada Evolve or ask a XSpada rep.