Skip to content

feat: JSON viewing — collapsible, syntax-highlighted tree - #26

Open
exilis wants to merge 5 commits into
masterfrom
feat/json-viewer
Open

feat: JSON viewing — collapsible, syntax-highlighted tree#26
exilis wants to merge 5 commits into
masterfrom
feat/json-viewer

Conversation

@exilis

@exilis exilis commented Sep 2, 2026

Copy link
Copy Markdown
Owner

What

.json files now appear in the file-tree navigator and render as a collapsible, syntax-highlighted tree.

  • New viewJson viewer in web/viewers.js (registered for .json). Object keys, array indices, and typed primitives (string / number / boolean / null) are colour-coded; objects and arrays fold via a ▾/▸ toggle.
  • No external library (unlike the pdf/docx/xlsx/pptx viewers) — the viewer decodes + JSON.parses the file client-side. Invalid JSON falls back to raw text (best-effort, per the viewer contract).
  • tree.go isViewable now lists .json; the server serves it as application/json.
  • Styles in app.css use the existing palette vars, with light/dark variants for the type colours.

Tests

  • 6 new node:test cases in web/viewers.test.js: registry (getViewer('.json'), case-insensitive, isBinaryDoc), the pure jsonPrimitiveText mapping, and jsonNode DOM structure (primitive class, object toggle + quoted key, array index, empty {}), via a small DOM stub matching the existing renderMedia test style.
  • TestListDir_ListsJSON in tree_test.go.
  • go vet + go test ./... clean. Runtime-verified end to end: /api/tree lists .json, /api/file serves application/json.
  • Note: 2 pre-existing failures in allium.test.js / render.test.js are unrelated — they fail identically on clean master (fetch-mock/env), not introduced here.

Deploy

The pm2-run binary in the dev box is being updated to this build alongside the PR.

.json files now appear in the file tree and render client-side as a
collapsible, syntax-highlighted tree via a new viewers.js viewer:
- object keys / array indices / typed primitives (string/number/boolean/null)
  are colour-coded; objects and arrays fold via a ▾/▸ toggle.
- no external library (unlike the pdf/docx/xlsx/pptx viewers) — decode + parse
  happen in-browser; invalid JSON falls back to raw text (best-effort, per the
  viewer contract).
- tree.go isViewable now lists .json; server serves it as application/json.

Tests: 6 new node:test cases (registry + pure jsonPrimitiveText + jsonNode DOM
structure via a stub) and a tree_test.go case; runtime-verified end to end
(/api/tree lists .json, /api/file serves application/json).
Render JSON like JSON.stringify(x, null, 2) for readability: 2-space
indentation, a trailing comma on every item except the last, object members
as "key": value, and array elements with no index prefix (the previous
'0:'/'1:' data-explorer style read poorly as formatted JSON). Objects/arrays
stay collapsible. Tests updated (comma placement, no index prefix).
embed.FS files carry no modtime/ETag, so http.FileServer sent no cache
validators — a browser or CDN (Cloudflare, here) then served a stale
app.js/viewers.js after a redeploy, hiding the new JSON viewer until a manual
hard-refresh. Wrap the asset handler to always set Cache-Control: no-cache so
redeploys are picked up immediately (revalidation, not no-store).
…pe hatch)

Make index.html asset refs relative and mirror the embedded frontend under a
/v2/ prefix. Because the whole module graph then resolves under /v2/*, opening
the app at /v2/ reaches a set of URLs a CDN has never cached — the way to get a
guaranteed-fresh frontend when a stale /app.js is cached at the edge and can't
be purged from the host. Combined with the no-cache header this keeps future
deploys fresh; bump the prefix again only if another stale-cache incident hits.
Multi-line string values (e.g. a message body full of \n) now display across
actual lines instead of showing literal \n escapes — the JSON line container is
already white-space: pre-wrap. Quotes/backslashes stay escaped so the string
remains unambiguous; single-line strings are unchanged (JSON.stringify).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant