Skip to main content
V2 data forms combine a declarative event system with a sandboxed JavaScript runtime to add dynamic behavior to forms. Events are attached to components, scripts run in QuickJS WebAssembly, and triggers react to changes in the underlying document. This page covers all four pieces and how they fit together.

Event System

Events are declared on any UINode via the events property. Each key is a component event name, and the value is a single EventConfig or an array of them.

EventConfig Fields

Handler Types

  • script — evaluates target as an inline JavaScript expression with access to ctx and the kodexa.* bridge.
  • scriptRef — calls a named function from the form’s scripts or scriptModules registry.
  • emit — re-emits the event from the schema root so parent components can listen.
  • store-action — dispatches a Pinia store action (reserved for future use).
  • bus-event — publishes on the application event bus (reserved for future use).

Example: Click and Change Handlers

Multiple handlers can be attached to the same event by passing an array of EventConfig objects. Each handler’s condition is evaluated independently.

QuickJS Runtime

All scripts run in a QuickJS WebAssembly sandbox — isolated from the browser, memory-safe, and protected by a configurable execution timeout.

Timeout Configuration

The default limit is 1000ms. If a script exceeds it, the runtime throws a "Script error: interrupted" error.

Defining Scripts

Inline — short expressions placed directly in events[].target:
Named scripts — reusable functions in the form’s scripts dictionary:
Named scripts are invoked through scriptRef event handlers or computed bindings on a UINode.

Script Modules

For scripts that need documentation and input/output metadata, use scriptModules. A ScriptModule wraps a function with additional fields:

Document API

Scripts can access the current document through the loadDocument() global, which returns a read-only document proxy. This API mirrors the server-side document wrappers, so scripts work the same way in both environments.

Document Methods

Data Object Methods

Attribute Methods

getValue() returns the first non-null value in this priority order: decimal, boolean, date, dateTime, integer, string.

Write Operations

To mutate the document, obtain a writable proxy through the bridge:
Writable proxies add these methods:
  • Document: createDataObject({path, taxonomyRef?}), deleteDataObject(uuid)
  • Data object: addAttribute({tag, path, value?}), addChild({path})
  • Attribute: setValue(value), setStringValue(value)
Write operations require both document:read and data:write bridge permissions.

Example: Sum Line Item Amounts

Script Triggers

Script triggers react to changes in data attribute values. They are declared as a scriptTriggers array on the form definition and invoke a named script whenever one of the watched attribute paths changes.
When any attribute matching lineItem/amount or lineItem/quantity changes, the recalcTotal script runs after a 300ms debounce window.

Event Triggers

Event triggers react to WASM document events such as attribute changes, object creation, and validation results. They are declared as an eventTriggers array on the form.
Additional event types emitted by the WASM layer include deleted:dataObject, deleted:dataAttribute, recalculated:dataAttribute, and validationCleared:dataAttribute. Use these with event triggers to keep form state synchronized with document changes.

Next Steps

Bridge API

Full kodexa.* API reference with permissions and service bridges

Data Binding

Context variables, expressions, and scoped data