Embed JSON editing: validate the captured draft

A temporary JSON typo should not update committed settings. Keep an editable draft separate and publish only the exact revision that passed validation.

The editor starts with retries two and enabled false in both states. A valid retries-three draft commits after an asynchronous local check; retries four and the string “false” are rejected. Editing during pending validation invalidates that candidate. This is a dependency-free fixed-schema editor, not a loaded JSONEditor library.

Embed JSON editing: validate the captured draft
Embed JSON editing: validate the captured draft
Open the full example ↗

Work through the example

Replace the draft with {"job":"demo","retries":3,"enabled":false} and Commit. Only the committed pane changes after validation. Retry with retries four to see the range error while committed retries remains three. Capture delayed candidate, edit the draft, then Resolve delayed validation to inspect stale-candidate rejection deterministically. Reset retires old work and restores both original states.

Keep parse errors, schema errors and retired validation results separate. None may publish a candidate. Validation belongs to the captured revision, not whichever text happens to be current when a callback resolves. The delayed controls make that race inspectable, while Reset retires the candidate and restores both states. Confirm a real editor library’s snapshot and Promise behavior separately when integrating it.

Begin with three fields and a fixed local schema

Use this original JSON value as both the initial draft and the initial committed configuration:

{"job":"demo","retries":2,"enabled":false}

JSON keys and the job value use double quotes. The boolean false has no quotes. Keep those details visible rather than showing a JavaScript object literal and calling it JSON.

Define schema revision S1 as a root object with these constraints:

Property Required type Additional constraint
job string No further restriction in this fixture
retries integer Inclusive minimum 0 and maximum 3
enabled boolean true or false

All three properties are required. Set additionalProperties to false at the root, with the three property definitions in that same schema object. No remote references or network validation are needed.

An authored schema specification is:

{
  "type": "object",
  "properties": {
    "job": {"type": "string"},
    "retries": {"type": "integer", "minimum": 0, "maximum": 3},
    "enabled": {"type": "boolean"}
  },
  "required": ["job", "retries", "enabled"],
  "additionalProperties": false
}

The JSON Schema object reference explains required properties and closing an object against extra properties. Its numeric reference describes integer values and inclusive bounds; the boolean reference distinguishes booleans from other values. For example, 2.0 is still an integral numeric value, while 2.5 is not. Do not reject 2.0 merely because the source text contains a decimal point.

Show draft, validation status, and committed value separately

Keep the editable draft, current validation status and read-only committed JSON in separate regions. Label the committed region “Accepted in this page session.” It is not a server configuration, account setting, or durable stored record.

At initialization, the draft and committed values both contain retries 2 and enabled false. Identify that committed value as the supplied original fixture; do not invent a completed validation run. Commit still requires current validation whenever the reader proposes a new candidate.

An edit changes the draft revision and retires any acceptance attached to the previous revision. It must not mutate the committed object through a shared reference. Use separate copies for the draft, captured candidate, and committed value.

Check each of these changes from the original draft:

Draft change from the original Syntax status Schema expectation Committed value after blocked Commit
retries becomes 4 Parses Outside 0–3 retries 2, enabled false
enabled becomes "false" Parses String is not boolean retries 2, enabled false
retries becomes 2.5 Parses Not integer retries 2, enabled false
Remove enabled Parses Required property missing retries 2, enabled false
Add an extra property Parses Extra property rejected retries 2, enabled false
Break the JSON text syntax Parse failure Candidate unavailable retries 2, enabled false

Recreate this example

Build one self-contained responsive HTML example titled “Embed JSON editing: validate the captured draft” for readers completing the stated task. Return the complete HTML with embedded CSS and JavaScript. Use no remote fonts, libraries, images, requests, account connections, or saved-state claims.

Local textarea JSON editor, no external library. Initial draft/committed {"job":"demo","retries":2,"enabled":false}. Fixed schema exact keys job/retries/enabled; string/integer0..3/boolean. Commit captures parsed candidate and monotonic revision, validates via Promise, publishes only unchanged current revision. Invalid syntax/schema leaves committed unchanged. Buttons Capture delayed candidate and Resolve delayed validation expose race: edit after capture => stale rejection. Reset restores both original values and retires pending candidates. Show revision and error feedback. Label handwritten validator honestly, distinguish app-level commit from storage. Library validate API discussion remains a native integration next step.

Use a two-state configuration editor with separate draft, revision status and committed source design with a compact header. Keep the actual sample data, controls, and useful default result visible early on a 360px-wide screen. Use readable text at least 16px, generous paragraph spacing, strong contrast, semantic labels, visible keyboard focus, and wrapping source blocks. Stack records on narrow screens rather than forcing a wide table.

Wire each action to an explicit type=button click handler using element selectors; the host permits scripts but blocks form submission. Update the visible result when the described action occurs. Show specific error feedback for invalid or missing input and clear stale feedback after dependent inputs change. Use plain text when displaying user values.

The local fixed-schema validator is handwritten; no JSONEditor library, backend or persistence is connected. Keep the source fixture and worked teacher or developer example distinct from actual user records. Include the domain-specific explanation and next check beside the result. Provide no fake download, send, deployment, approval, or persistence button. Everything operates locally for the current page session.

Review the prepared copy in NOS

Test the delayed edit race before connecting the editor to application settings. A prepared HTML explanation of draft versus committed state can be reviewed in NOS, with eligible static validation notes edited visually. Keep the schema and native integration tests authoritative for any real commit transaction.

Keep reading