Extensible schema with custom elements and chart types

Problem

Dataface's chart types and layout elements are hardcoded in the core engine. A user who wants a custom visualization (e.g., a Sankey diagram, a custom scorecard, a form input, a specialized table variant) has no path to add it without modifying core code. This limits adoption in organizations with unique visualization needs and prevents a plugin/extension ecosystem.

json-render's defineCatalog demonstrates the pattern: developers register typed components with prop schemas, and the entire system (validation, rendering, AI prompts, editor tooling) automatically understands them. The key insight is that the schema is the extension point — adding a component to the catalog makes it available everywhere.

For Dataface, this means a user should be able to: 1. Define a custom chart type (or layout element, or form input) in their project 2. Register it with a typed schema (what props it accepts, what data it expects) 3. Provide a renderer (SVG, HTML, or Vega-Lite spec builder) 4. Have it work with compilation, AI generation, theming, and editor tooling — automatically

Context

• Initiative (graph-library): M3 chart and visualization extensibility — external product research, tiered extension model, M2 versioning coordination.
• Research origin: ai_notes/research/json-render-deep-dive.md — "Typed Catalog with Validation" and "Key Differences" sections.
• Chart type enum: ChartType in dataface/core/compile/types.py — currently a closed enum
• Chart renderer registry: dataface/core/render/chart/renderers.py — dispatches to renderer by chart type
• Existing plugin-like patterns: ai_notes/suite/PLUGINS.md — earlier plugin system thinking
• Vega-Lite custom specs: issue-197-p3-support-raw-vega-lite-specs-in-dataface-yaml — related (raw Vega-Lite passthrough as one form of custom viz)
• Depends on: declarative-schema-definition-outside-python-code — extensibility needs a schema contract to extend
• Enables: schema-derived-ai-prompts-from-compiled-types — custom elements automatically appear in AI prompts

Possible Solutions

A. Plugin registry in project dataface.yml

Users register custom elements in their project config:

# dataface.yml
plugins:
  charts:
    sankey:
      schema: ./plugins/sankey/schema.yml
      renderer: ./plugins/sankey/renderer.py
    scorecard:
      schema: ./plugins/scorecard/schema.yml
      renderer: ./plugins/scorecard/renderer.py

Each plugin provides a schema (fields, types, defaults, description) and a renderer (Python class implementing the render interface). The compiler loads registered plugins and merges their schemas into the catalog.

Pros: Simple, project-local. No global installation. Easy to share via git. YAML-native. Cons: Python renderers limit portability. Need to define the renderer interface contract.

B. Chart type = Vega-Lite spec template Recommended for charts

For chart-type extensions specifically, let users define custom chart types as parameterized Vega-Lite spec templates:

# plugins/sankey/schema.yml
type: chart
name: sankey
description: "Sankey flow diagram"
fields:
  source: { type: field_name, required: true, description: "Source node field" }
  target: { type: field_name, required: true, description: "Target node field" }
  value: { type: field_name, required: true, description: "Flow value field" }
vega_lite_template: ./sankey.vl.json

The template is a Vega-Lite spec with {{field}} placeholders that get filled by the field mappings.

Pros: No Python needed for chart extensions. Leverages Vega-Lite ecosystem. Templates are portable. Cons: Only works for Vega-Lite-expressible charts. Custom SVG renderers need a different path.

C. Hybrid: Vega-Lite templates for charts, Python plugins for everything else

Chart types use Vega-Lite templates (B). Non-chart elements (layout components, form inputs, custom renderers) use the plugin registry (A). Both register against the declarative schema.

Pros: Best UX for the common case (charts) while supporting arbitrary extensions. Cons: Two extension mechanisms to document and maintain.

Plan

1. Define extension targets, registration shape, and non-negotiable safety boundaries.
2. Prototype one narrow custom chart path using the declarative schema contract.
3. Specify how validation, rendering, docs, and AI prompts discover registered extensions.
4. Write rollout guidance and explicitly separate first-phase support from later plugin ambitions.

Implementation Progress

Review Feedback

• [ ] Review cleared