Data Lifecycle

Load-once, in-memory editing model

• When a user opens a project, the web app loads the JSON files (e.g., project.wh_proj, schematic.wh_sch) into in-memory JavaScript objects.

• The user interacts with the UI (drag objects, create wires, label nets), and all changes are reflected in the in-memory data, not immediately written back to disk or storage.

• When the user clicks "Save", the updated JSON is written to the local file system (Electron) or sent to the backend (Web app).

• You can optionally auto-save at intervals or on specific actions.

Data Validation

• Validate project files when loading a project to ensure proper functionality and safety

• We can use ajv to validate JSON against schemas generated with JSON Schema directly in Javascript

Immutable Data & Undo / Redo Functionality

• Immutable edits. This means changes result in a new copy of the project data object. A limited number of these are stored in memory allowing undo / redo functionality.

• For performance: only clone the part of the tree you're editing, not the whole project data.

• Undo/redo becomes trivial: You just keep a stack of past states and revert as needed.

• Debugging is easier: You can snapshot state at any time.

• Pure functions are easier to reason about — no side effects.

• Prompting users to save work: track unsaved work by enabeling a flag (ex: isUnsaved) when an edit is made

• Immer is a JS package designed for dealing with immutable data structures that is a potential candidate for this

File I/O

Electron App

• All file operations (open, save, export) happen on the user’s local machine.

• Use fs module in Node.js to read/write JSON.

• Changes remain in memory until the user saves.

• Optionally track a “dirty” state to know if there are unsaved changes.

Web App

• The HTML, CSS, and JS files are downloaded to their browser.

• A new JavaScript runtime is spun up per browser tab.

• Each tab gets its own copy of all global state, including:

  • Canvas state

  • Wire/net/object data

  • Undo/redo history

  • Project file reference

User Concurrency

User concurrency is naturally supported because everything runs in the client's browser / app

• Project data lives only in memory on the client side.

• Users explicitly load their own project files (i.e., no shared backend or autosyncing).

• No accounts or persistent shared storage.