Field: Custom Field Field

[lattln]

Research and design component catalog import for MUI Web UI custom fields

Description
We already support custom components through the existing component registry. This ticket is about something bigger: adding a Custom category to the builder ToolPanel that can expose a large, pre-existing component library such as MUI Web UI as a browsable/draggable catalog of field components.

The challenge is scale. MUI Web UI contains many components, and we cannot manually register each one individually. We need a strategy for automatically discovering, classifying, and surfacing those components inside eSheet so they can be used as custom fields or field-like building blocks.

This should be treated as a research and design ticket first, because the solution likely requires a cataloging pipeline, metadata normalization, and a clear mapping between imported components and eSheet field definitions.

Key Problem

• eSheet already has a custom component registration path.
• What we need now is a way to ingest a large component library and expose it as a custom component category in the builder.
• The imported components should appear in the left-side ToolPanel, likely grouped under Custom, and be draggable into the form just like native fields.

Research Goals

• Determine how to discover all available components from MUI Web UI or another source library.
• Determine whether discovery should come from:
  • Storybook metadata,
  • package exports,
  • source code scanning,
  • generated manifests,
  • or a hybrid approach.
• Define how discovered components are categorized and displayed in the ToolPanel.
• Define how a discovered component maps into an eSheet field definition.
• Define how eSheet should handle props, defaults, labels, slots, and required metadata for imported components.
• Determine whether imported components should be:
  • wrapped as a new custom field type,
  • adapted into a common field contract,
  • or cataloged as UI-only components with a field wrapper.
• Identify the minimum metadata needed for each component to make it usable in the builder.

Important Constraints

• This is not just generic custom field support.
• The solution must scale to a large external library.
• Manual per-component registration is not acceptable.
• The system should support browsing a large catalog, not just one-off custom field creation.

Questions to Answer

• How do we ingest a large component library automatically?
• What source of truth should be used for component metadata?
• How do we group components into a Custom category in the ToolPanel?
• How do we distinguish native fields from imported UI components?
• What is the adapter layer between a catalog component and an eSheet field definition?
• How do we keep the catalog in sync when the upstream library changes?
• What happens when a component is deprecated, renamed, or removed upstream?

Acceptance Criteria

• A documented approach exists for importing a large component catalog into eSheet.
• The approach does not rely on manually registering every component.
• The builder can present imported components under a custom category.
• The design explains how catalog items map to eSheet field definitions.
• The design identifies how metadata is sourced and maintained.
• Risks and unknowns are documented, especially around scalability and schema compatibility.
• A follow-up implementation plan is defined.

Notes
This should likely be implemented as a catalog/import pipeline, not just a registry feature. The existing registry can remain the runtime mechanism, but the ticket should focus on how to generate and maintain that registry at scale from an upstream component library.