For the complete documentation index, see llms.txt. This page is also available as Markdown.

Widget Reference

A practical, widget-by-widget reference for @openg2p/registry-widgets. It covers JSON widget configuration, data binding via widget-data-path, validation and formatting, conditional show/hide/enable/disable/require logic, static and API data sources, section/panel rendering in RegistryView / CRView / IntakeForm modes, theming and i18n, cascade events, and how to register custom widgets.

Table of contents

Introduction

The OpenG2P Registry UI Widgets library builds dynamic forms from JSON configurations. Current capabilities include:

  • 22 pre-built widgets (inputs, tables, display/identity, geo hierarchy, docs, lookup, ID auth)

  • Redux-based state management for values, errors, touched, loading, and data sources

  • Flexible data binding with single-path and multi-path maps

  • Validation with built-in rules and Zod schemas

  • Conditional logic including dynamic require

  • Host-driven API data sources via dataSourceRequestHandler

  • i18n via host t function and schema translation helpers

  • Theme tokens applied as CSS variables on WidgetProvider

  • Extensible registry for custom widgets

  • SectionBuilder tooling for authoring schemas

Package version context: @openg2p/registry-widgets (see package for current version). Peer stack: React 19, Redux Toolkit, Zod 4.

Installation and setup

1

Install the package

2

Install peer dependencies

Optional (host i18n): i18next and react-i18next if you pass their t into WidgetProvider.

3

Basic setup

Default widgets register automatically when the package is imported.

4

Optional: translation and theme

Core concepts

Widget configuration

Every widget config follows BaseWidgetConfig. Required fields:

  • widget — registered name (e.g. "text", "select", "geo-hierarchy")

  • widget-id — unique id in the form

Common optional fields: widget-type, widget-label, widget-data-path, widget-required, widget-readonly, validation, format, data source, options, cascade, column span.

useBaseWidget hook

Foundation for most widgets:

Widget registry

Basic usage

Rendering a single widget

Using sections and panels

Widget configuration

Basic configuration properties

Example: complete text input configuration

Data binding

Single path binding

Multi-path binding

Accessing data

Values live in the Redux widget store under path keys. WidgetProvider hydrates from schemaData via setValues. Widgets read/write through useBaseWidget / path utilities.

Getting other field values

Validation

Built-in validation rules

pattern takes precedence over validationType when both are set.

Predefined validation types

  • email

  • phone

  • url

Zod schema validation

Manual validation

Use setError from useBaseWidget, or SectionsContainer form handle methods: validate(), validateAndGetData(), getFormData(), getStructuredData().

Conditional logic

Actions: show | hide | enable | disable | require.

Single rule

Multiple actions

Operators

  • equals, notEquals

  • notEmpty, empty

  • greaterThan, lessThan

  • contains, notContains

Data sources

Used by select, multi-select, radio, checkbox, and related lookups.

Static

API

Dependent API (dependsOn)

Prefer widget-cascade when you need clear-on-change / reload-on-change with debounce.

Schema reference

Geo hierarchy data source

geo-hierarchy expects an API data source with levelsEndpoint and valuesEndpoint (not a plain options list):

Formatting

Date / datetime

Number

Text

Phone

Boolean

Widget cascade

Clear and/or reload a child API data source when parent widgets change:

Events: widget:change, widget:blur, widget:focus, widget:reload, widget:clear.

Section modes

Pass mode to SectionsContainer:

Mode
Behavior

RegistryView (default)

View sections; optional edit/save per section; hideEditButton / section-hide-edit-button

CRView

Change-request review; audit footer from schema/store

IntakeForm

Accordion sections; isDraft controls editability; form handle for full-form validate/submit

Section config extras:

  • section-editable

  • section-hide-edit-button

  • section-column-span

  • section-supporting-documents (path, type, accept, max size, required, label)

Widget reference

Notes:

  • widget-data-path may be a string or a map of keys → paths

  • Layout widgets array-widget, iterable-accordion, and simple-table are not registered in the current library; use table / dialog-table for repeating structured rows

Default widget catalog (22)

text, textarea, number, boolean, date, datetime, select, multi-select, radio, checkbox, file, phone, display, profile, table, dialog-table, header-section, scores-display, id-authentication, register-lookup, geo-hierarchy, docs


Input widgets

Text Input Widget (text)

Single-line text input with masking, character filters, and case control.

Widget name: text · Type: input

Features: HTML input types, charset filters, masks, char counter.

Text Area Widget (textarea)

Multi-line text.

Number Input Widget (number)

Integers/decimals with separators, rounding, alignment, signed values, format-on-blur.

Phone Input Widget (phone)

Date Input Widget (date)

Defaults: "today" supported for default value.

DateTime Input Widget (datetime)

File Input Widget (file)

Upload with preview and serialization for storage.


Selection widgets

Select Widget (select)

Multi Select Widget (multi-select)

Stores an array of selected values. Searchable dropdown with optional sorted options.

Radio Widget (radio)

Checkbox Widget (checkbox)

Single boolean or multi-value list depending on data source / usage.

Boolean Widget (boolean)

Control types: checkbox | radio | toggle. Representations: true-false | yes-no | on-off | custom.


Geo and documents

Geo Hierarchy Widget (geo-hierarchy)

Cascading location selects (e.g. Region → Zone → Woreda). Persists the deepest selected level value; optional hierarchy JSON for hydration.

Layout: By default levels fill top-to-bottom across up to 3 columns (columnSpan / auto from level count). Optional widget-geo-layout forces explicit column counts. Prefer a full-width section (section-column-span: 3).

Docs Widget (docs)

Fixed upload slots in a three-column layout.

Stored value is an object keyed by document-key (serialized file or view URL). document-accept and document-max-size (bytes) are required per slot.


Display and identity widgets

Display Widget (display)

Read-only formatted value.

Profile Widget (profile)

Identity strip: image, name, id via multi-path binding.

Header Section Widget (header-section)

Record summary header: image, name, functional ID, status, completion/ideal scores, audit stamps.

Scores Display Widget (scores-display)

Read-only list of computed scores, newest first.

Expected array items:


Domain widgets

ID Authentication Widget (id-authentication)

Shows authentication status fields and starts a provider login (popup or optional iframe). Uses multi-path binding and widget-auth-config.

Host typically listens for browser events / postMessage success (default type openg2p:oidc:success). Optional reloadOnSuccess.

Register Lookup Widget (register-lookup)

Search another register and store the selected record id.


Table widgets

Table Widget (table)

Inline editable table with per-column widget configs and add/remove/edit operations.

Set widget-readonly: true for a static table.

Dialog Table Widget (dialog-table)

Rows are edited in a modal dialog. Supports column-group for dialog field grouping and per-column conditional actions evaluated against the current row.

Row change markers (ADD / UPDATE / DELETE) use theme success/warning/error colors for visual review.


Widget configuration summary

Common properties:

  • widget, widget-id (required)

  • widget-type: input | layout | table | group

  • widget-label, widget-data-path, widget-data-default

  • widget-required, widget-readonly, widget-column-span

  • widget-data-placeholder, widget-data-helptext, widget-data-tooltip

  • widget-data-validation, widget-data-format, widget-data-source, widget-data-options

  • widget-cascade

  • Table: widget-data-columns, widget-data-operations, widget-data-add-label

  • Geo: widget-geo-layout, widget-geo-hierarchy-path

  • Docs: documents, widget-total-docs

  • Auth: widget-auth-config

  • Lookup: widget-lookup-config

  • Header: widget-field-config

Creating custom widgets

1

Create the component

2

Register it

3

Use it in a schema

Prefer useBaseWidget so validation, conditions, data sources, and Redux stay consistent.

Advanced patterns

Intake form with form handle

Dynamic form generation

Map a server field list to BaseWidgetConfig[] and place them under panels/sections. Keep widget-id and widget-data-path stable across regenerations.

Section-level change tracking

onSectionSave receives structured SectionChanges (old/new values) suitable for change-request payloads.

Section builder

Use SectionBuilder / VisualBuilderPanel / JSONEditorPanel during development to edit schemas visually and as JSON.

Internationalization

i18n is host-provided. There is no built-in initI18n in the current package.

Pass t to WidgetProvider

Translate schemas programmatically

Also available: translateWidgetConfig, translatePanelConfig. Keys that look like translation keys (contain . or :) are passed through t with fallback to the original string.

Widgets that receive t via context use helpers such as tSchema for labels and option text at render time.

Theming

Theme tokens cover colors, section, panel, button, and widget chrome (including table states). They are applied as CSS variables on the provider root.

Best practices

Widget IDs

Use stable, unique ids (person-first-name). Avoid regenerating ids on every render.

Data paths

Prefer clear namespaces (register-id.full_name). Align multi-path keys with what each widget documents (profile, header-section, geo-hierarchy, id-authentication).

Validation

Put shared rules in widget-data-validation. Use Zod for cross-field or complex rules. Call section/form validate before submit.

Conditional logic

Prefer actions arrays when a field must both show and require. Keep condition field paths aligned with store paths.

Data sources

Always provide dataSourceRequestHandler in production. Prefer service + endpoint over deprecated url. Use cascade for parent/child selects.

Performance

Keep section schemas reasonable in size. Use section-level edit instead of editing the entire registry at once. Avoid unnecessary schemaData object identity changes.

Type safety

Type configs with BaseWidgetConfig, SectionConfig, UISchema, and SectionMode.

Troubleshooting

Widget not rendering

  • Confirm the widget name is registered (widgetRegistry / default list)

  • Ensure the package import ran (defaults register on import)

  • Check isVisible / conditional hide rules

Validation not working

  • Set widget-required and/or widget-data-validation.required

  • Ensure blur/change fired (touched)

  • For Zod, pass a real schema instance (not JSON)

API data source not loading

  • Provide dataSourceRequestHandler on WidgetProvider or SectionsContainer

  • Verify service, endpoint, method, and valueKey / labelKey

  • Check browser network/console for host handler errors

Conditional logic not working

  • Confirm field path matches stored values

  • Use actions when multiple rules are needed

  • Remember dialog-table conditions evaluate against the row context

Geo hierarchy empty

  • Confirm handler implements levelsEndpoint and valuesEndpoint responses

  • Ensure hierarchy path is present for edit hydration

  • Check required flag on the first level

TypeScript errors

  • Import types from @openg2p/registry-widgets

  • Align Zod peer major version with the package (zod ^4)

Conclusion

@openg2p/registry-widgets provides a schema-driven form system tailored to OpenG2P registry workflows: section modes for view/intake/CR review, twenty-two default widgets spanning inputs through geo hierarchy, documents, lookup, and ID authentication, plus host-owned APIs, theming, and translation. Use this reference alongside the overview document for architecture context, and the example-ui-schema folder in the package for copy-paste configs.

Last updated

Was this helpful?