V2 data forms can declare keyboard shortcuts as a top-level array on the schema. Each entry binds a key combination to a named script and is registered under a per-form scope, so a form effectively resets all of its shortcuts every time it mounts — you never have to manually un-register them.Documentation Index
Fetch the complete documentation index at: https://developer.kodexa.ai/llms.txt
Use this file to discover all available pages before exploring further.
Why declarative
Shortcuts live in the schema next toscripts and bridge. The form author writes a key → script mapping; the platform handles registration, scoping, and cleanup. Because each shortcut points at a named script, the same script can be invoked via a hotkey, a button click, a trigger, or a service-bridge response without duplicating code.
Schema
Add ashortcuts array to the form’s top-level definition:
FormShortcut Fields
| Field | Type | Required | Description |
|---|---|---|---|
key | string | Yes | Primary binding (e.g. "control+1", "meta+shift+s") |
altKey | string | string[] | No | One or more alternative bindings that also fire the script |
description | string | Yes | Label shown in the keyboard-shortcuts help dialog (⌘/) |
group | string | No | Help-dialog group: "navigation", "zoom", "data-entry", "document", or "ui" |
scriptRef | string | Yes | Name of a script in the form’s scripts map to invoke |
Lifecycle and scoping
Every shortcut is registered under the scopeform:<viewId>. The platform:
- On mount — clears the scope (so a stale registration from a previous mount is gone), then registers each entry under the scope.
- On
shortcutschange — runs the same clear-then-register cycle automatically. Hot-reloading a form during development replaces the bindings cleanly. - On unmount — clears the scope. Shortcuts from other forms or the global help dialog are untouched.
If your form’s
key collides with a global shortcut already in the help dialog (for example meta+/), the existing global binding wins and the form’s is silently dropped. Prefer keys not used globally.Inside the script
Scripts referenced byscriptRef follow the standard V2 signature — a function of (ctx, bridge):
ctx.shortcut payload ({ key, description, scriptRef, ... }) is added by the shortcut dispatcher so a single script can branch on which binding fired it.
What scripts typically do
The most common actions a shortcut performs are spatial navigation, attribute focus, and data-object manipulation — all available through the bridge:Permissions
Shortcut scripts call the same Bridge API as any other V2 script, so they obey the samebridge.permissions contract. A shortcut that calls bridge.navigation.setPage(...) needs "navigation" in the form’s permissions array; one that calls bridge.data.addDataObject(...) needs "data:write". Permission errors surface to the browser console and the shortcut becomes a no-op.
Help dialog
Registered shortcuts appear in the global keyboard-shortcuts help dialog (open with⌘/ on Mac or Ctrl+/ on Windows/Linux), grouped by the optional group field. Use a clear description — that’s what users will see when they’re hunting for a key.
Example: invoice review form
A reviewer-oriented form that binds the number keys to the document’s classification groups and usesTab-like flow to move between common fields:
Conformance
The shortcut dispatcher and Bridge API are covered by a conformance suite inkodexa-ui/src/schema/runtime/conformance/. Each binding behaviour ships as a paired .js + .expected.json script that runs against a stub-store-backed Bridge — the suite catches binding regressions before they reach the browser.