Extending Widgemo Overview
Use this section when built-in config is no longer enough and you need to register new behavior through widgemoRegistry.
Extension Paths
| Extension path | Use when | Registry/API surface |
|---|---|---|
Custom renderAs | A field value needs a new visual treatment | registerWidgemoRenderAs |
| Custom field type | A reusable domain field needs its own semantic type | registerWidgemoFieldType |
| Custom mode | The content area needs a new layout strategy | registerWidgemoMode |
| Custom icon | Config should reference icon names from your own icon set | registerWidgemoIcon |
| Lifecycle hook | You need runtime interception at named core hook points | registerWidgemoHook |
Choose the Smallest Surface
| Goal | Prefer | Why |
|---|---|---|
| Change how one value looks | Custom renderAs | Smallest and most config-friendly extension |
| Reuse a domain-specific field category | Custom Field Types | Adds semantic meaning, not just presentation |
| Replace table/grid/board/carousel/chart with a new layout | Custom Modes | Moves the whole content area to a new renderer |
| Use branded or domain-specific icon names in config | Custom Icons | Keeps config icon references stable and reusable |
| Intercept runtime lifecycle events | Extension API | Hook surface is separate from layout and field registration |
Recommended Order
- Exhaust built-in config first:
mode,fields,renderAs, actions, theming. - Read Extension API for the exact registry contracts.
- Pick one extension surface and keep it narrowly scoped.
- Use namespaced registration names (
acme.timeline,acme.swatch,acme.flag) to reduce collisions.