Storage & Persistence

This is a technical record of the archived application. It does not describe a current or supported SnapDock storage format.

Storage Location

The Electron main process stored the complete application state in:

<Electron userData>/snapboard/snapboard-data.json

<Electron userData> is platform-specific. The application obtained it through Electron’s app.getPath("userData"); it did not hard-code a Windows or Linux profile path.

The main process derived the filename from a basename-safe storage key, created the directory when necessary, and wrote formatted UTF-8 JSON. Reads parsed that JSON and returned null on a missing file or any read/parse error. Writes returned false on failure, but the renderer did not surface that result to the user.

Stored Shape

The final file held all boards together:

{
  "boards": [
    {
      "id": "generated-id",
      "name": "My Board",
      "columns": [
        {
          "id": "generated-id",
          "title": "To Do",
          "cards": [
            {
              "id": "generated-id",
              "title": "Example",
              "body": "Markdown text",
              "file": null,
              "createdAt": 0,
              "updatedAt": 0
            }
          ]
        }
      ]
    }
  ],
  "currentBoardId": "generated-id"
}

There was no .db backend, per-board database, schema version, encryption layer, or cloud synchronization.

Automatic Saving Behavior

State-changing methods first copied the state to browser sessionStorage, then reset a 250 ms timer. When the timer elapsed, the complete payload was written through the preload bridge to the JSON file. Initial setup saved immediately.

The following implemented state changes scheduled a save:

• board, column, and card mutations performed through the state module;
• selecting a current board;
• adding, removing, or replacing a card’s file reference;
• moving a card through the state operation.

Whether a given change was reachable depended on the unfinished UI wiring described in Boards & Columns and Cards & Markdown.

On startup, session storage was preferred over the disk file when present. Valid stored boards were normalized and missing IDs/default fields were repaired. There was no formal database migration framework.

Backups, Import, and Export

SnapBoard had no implemented backup, restore, board import, or board export command. The source contained no .sb serializer or parser. Copying the JSON file outside the application was not an in-app workflow and the repository supplied no tested restore procedure.

File references remained absolute paths and were not copied into the data file. Moving either the reference target or the application data between machines could therefore break those references without warning.