Skip to content

UIForge v0.8.0

Date: 2026-09-26 Commit: a200371

The first usable release of UIForge (v0.1.0 through v0.7.0 of this module path predate its extraction and are unrelated) — a specification-driven UI composition platform. Pages are declarative PageSpec JSON documents (apiVersion: ui.plexusone.dev/v1), validated against a versioned component registry, and rendered by interchangeable runtimes. Code defines component capabilities; the spec composes and configures them.

Highlights

  • One IR, two renderers. The same PageSpec renders through React (@plexusone/uiforge-renderer) or standard web components via Lit (@plexusone/uiforge-renderer-lit). Both emit an identical data-uiforge-* DOM vocabulary — layouts, cells, regions, navigation, loading/error markers — verified by a fixture-driven conformance suite that runs every golden PageSpec through both renderers.
  • Registry-governed composition. Every component type resolves to a ComponentSpec manifest (properties schema, data inputs, events, capabilities, layout constraints). Page validation enforces registered types, required data inputs, property schemas, version compatibility (1.2, 1.2.3, ^1.2 forms), interaction wiring, and per-profile constraints (allowed layouts and namespaces, required slots, nesting depth). External manifests load from JSON files or directories.
  • Four builtin component namespaces (25 manifests, 18 rendered in both renderers): core.* (text, image, button, card, tabs, modal), analytics.* (metric, filter, table, line-chart, bar-chart, gauge), application.* (input, select, checkbox, form, record-detail, record-list, action-bar, badge), and assistant.* (agent-conversation contracts).
  • Async data-source runtime. Bindings resolve through tiers: static and state synchronously; registered DataSourceConnectors asynchronously with loading and error states, ${...}-evaluated parameters, per-component caching, and re-fetch via the component.refresh interaction action; connector-less sources fall back to binding defaults so pages render without any data infrastructure.
  • Design-system governance via design-system-spec. Components consume a fixed semantic token contract (--uiforge-primary, --uiforge-surface, …) named after the DSS semantic vocabulary. The theme package maps any DSS document onto that contract — including white-label var() references to the host brand's own CSS custom property prefix — and themes scope per page instance for multi-tenant embedding.
  • Shared spec package. @plexusone/uiforge-spec holds the UISpec TypeScript types (mirroring the Go source of truth) and the framework-free expression, state, interaction, and data engines consumed by both renderers.

Packages

Package Language Purpose
github.com/plexusone/uiforge (uispec, registry, pkg/*, schema, theme) Go IR types, registry + validation, engines, generated schemas, DSS theme adapter
@plexusone/uiforge-spec TypeScript Shared types + framework-free engines
@plexusone/uiforge-renderer TypeScript/React React renderer
@plexusone/uiforge-renderer-lit TypeScript/Lit Web-components renderer (<uiforge-page>)

The npm packages are published: @plexusone/uiforge-spec, @plexusone/uiforge-renderer, @plexusone/uiforge-renderer-lit.

Verification

  • Go: 7 packages, unit + golden-fixture tests, golangci-lint clean; schemas regenerate deterministically and pass schemakit lint --property-case camelCase
  • TypeScript: 116 tests across the three packages (44 engine tests under plain Node, 33 React, 39 Lit), eslint + prettier clean
  • Five golden PageSpec fixtures (dashboard, agent-workspace, and application-profile record page) validate through the registry and render through both renderers

Try it

cd spec && npm install && npm run build && cd ..
python3 -m http.server   # from the repo root
# open http://localhost:8000/examples/demo/

Known limitations

  • Tabs and split-pane region content, core.tabs/core.modal renderer implementations, and runtime capability enforcement are roadmapped (see docs/specs/ROADMAP.md).
  • The assistant.* namespace ships manifests and React components; Lit implementations are roadmapped.

Roadmap pointers

Phase 3 (npm publish + Node CI, authoring utilities) and the standard patterns/templates layer are next; see docs/specs/ROADMAP.md for the full RMI breakdown.