A low-code form starts with a configuration contract

Validate the configuration before rendering

checkSchema requires version 1, a bounded number of fields and known field types. It rejects duplicate or reserved keys, conflicting numeric ranges and duplicate select values. Returning a structured clone also prevents an editor from accidentally sharing the original object with a preview.

The practical benefit is an understandable failure at import time. Otherwise, a configuration can appear to load and only break when a user submits a less common field.

Field keys belong to the data model

A field key should survive reordering and translation. Display labels can change without renaming stored values. The demo finds unused field_N keys when deleting and adding fields; using the current array length would collide after a deletion.

Once configurations persist, version changes need migration rules. Removing a field also raises a data question: whether to retain historical values, hide them or export them. The current browser demo has no persisted business records, so it does not yet answer that migration question.

Test values that look empty or valid

Using raw || an empty string would discard numeric zero. The implementation uses a nullish fallback and then trims text. Optional blank values bypass minimum-length checks, while required whitespace fails. Date validation also compares the parsed calendar day back to the original string.

// Run with Node from the website repository root.
import { validateField } from "./demos/low-code-form/schema.mjs";
const field = { key: "count", label: "Count", type: "number",
  required: true, min: 0, max: 10 };
console.log(validateField(field, 0)); // empty error string
console.log(validateField(field, "Infinity")); // validation error

Ten checks, with a defined scope

The passing suite covers independent cloning, key validation, supported versions and field limits, key allocation, blank values, email and enum rules, numeric bounds, calendar dates, invalid ranges and translated messages. It validates this small renderer contract.

Client validation helps users correct input; a backend must validate again. A larger form system would also need an explicit policy for conditional fields, asynchronous validators, unknown properties and configuration migration. Those features should come with separate tests.