Components Catalog

The frontend catalog defines the reusable interface families that can be used around generated sigMAX projects. It is not the place where business behavior is generated. It describes presentation building blocks that can expose generated contracts, runtime state, documentation, forms, lists and inspection screens in a consistent way.

Catalog Role

Generated projects often need small, predictable UI surfaces: a list of objects, a validated form, a detail view, a status panel, or a chart. The catalog keeps those surfaces reusable so they do not become one-off handwritten pages.

Catalog rule	Reason
Contract-driven props	Components should be configured from contracts, schemas or generated metadata.
Small composition units	A generated page can combine simple pieces instead of owning a large custom UI.
Runtime neutrality	Components present data and actions; they do not bypass runtime capabilities.
Inspectable output	The same generated metadata should be visible in docs, Studio and lightweight pages.

Component Families

Family	Use	Typical source
📊 Table	Collections, search results and structured lists.	Route schema, storage declaration, generated OpenAPI.
🧾 Form	Validated input and command parameters.	Request schema, contract constraints, allowed actions.
🔎 Detail	Object inspection and generated artifact metadata.	ObjectIR, agreements, component metadata.
📈 Stats	Operational or business counters.	Runtime metrics, health endpoints, generated summaries.
🧭 Chart	Visual summaries and comparison views.	Aggregated metrics or declared report shapes.
🧩 Card	Compact entity previews and navigation blocks.	Component catalog, route index, documentation metadata.
🛡️ Status	Health, validation and drift indicators.	Agreements, runtime checks, health endpoints.
🧪 Test Panel	Generated test status and validation feedback.	Test reports, drift reports, generation logs.

Shared Behavior

Every catalog component should follow the same baseline behavior:

predictable keyboard navigation;
compact layout that works in documentation and Studio surfaces;
clear empty, loading and error states;
no hidden network access outside declared runtime routes;
visible status when data is generated, stale or partially unavailable;
consistent formatting for dates, versions, hashes and validation states.

Current Boundary

The catalog is intentionally conservative during the beta phase. It should help present generated material, not become a custom application builder.

Roadmap

The next useful catalog step is to attach concrete examples to each family:

Next example	What it should prove
Table from route schema	Columns, labels, empty state and pagination can be generated predictably.
Form from request schema	Required fields and validation messages remain contract-aligned.
Detail from ObjectIR	Structured runtime output can be inspected without custom code.
Status from agreement	Validation and drift state can be shown consistently.