A JSON import into a local editor is a replacement operation. Treating it as a single assignment hides three separate states: the current working draft, the selected candidate and the user's decision.
Keep the candidate separate
Read and validate the selected file before assigning it to the working draft. Check its format, version, expected fields and size. A successful JSON.parse only establishes valid JSON syntax; it does not establish compatibility with your application's document format.
Make replacement explicit
After validation, show what will happen and offer cancellation. The current draft should remain unchanged while the dialog is open. If you offer a backup download, initiate it before applying the replacement and explain that users must keep the downloaded file. Starting a download does not prove that the user has a durable backup.
Do not erase unreadable saved data
If a stored string cannot be parsed, retain that raw string for recovery. Avoid immediately serialising a new empty document over it. A rescue download can preserve the original bytes while the user decides whether to reset the editor.
Review the boundaries
Use recognisable fictional fixtures. Check malformed JSON, a valid but incompatible object, a cancelled replacement, a confirmed replacement and unavailable browser storage. Reload after a successful import to inspect persistence. Keep the evidence for each scenario separate; one successful import does not demonstrate all failure cases.
These principles apply to notes, calculators and portfolio editors. The implementation details vary, but the boundary stays the same: a candidate file is not the current document until replacement is deliberately applied.
Top comments (0)