Schema import: keep the working form until validation succeeds

01 / Preserve something worth protecting

Enter a topic in the preview, then put invalid JSON in the configuration editor and apply it. The expected result is an error plus the original fields and input. Repeat with two fields sharing the same key: valid JSON alone does not make a valid form.

02 / Validate first, replace once

The import handler computes next = checkSchema(JSON.parse(json.value)) before assigning schema = next. If parsing or validation throws, the current schema and values are untouched. This sequencing is what protects the existing view.

A successful import intentionally clears preview values. A new schema can reuse a key with a different meaning. In contrast, ordinary reordering preserves values by key. Preservation is a product rule, not a universal default.

03 / Small edge cases expose the contract

Zero is a valid required number. An optional blank value should not fail a minimum-length rule. A date such as 2025-02-29 has a plausible format but is not a real calendar date. These examples are more informative than a single happy-path submit.

The schema limits field count and accepted types and rejects duplicate or reserved keys. Labels are written as text rather than executable markup. These constraints keep the renderer understandable; richer conditional logic would need its own specification.

04 / Check the core and the interface separately

All ten existing core tests passed, including independent copies, key rules, field limits, zero, ranges, enums and calendar dates. These tests do not assert that browser input survives an import error; that requires a separate interaction check.

The next step for a service-backed version is migration and server validation. Preview validation does not authorize a submission or prove that a backend accepts the same contract.

node --test demos/low-code-form/schema.test.mjs