Supersedes #68 (which folded panes into the default folder browser via a node_modules override — replaced by the cleaner opt-in design below).
Idea
Add a third selectable data browser alongside data-browser.js (json) and data-browser-folder.js (folder): a pane-aware browser, chosen with the existing switch as --browser panes. The two existing browsers stay byte-for-byte unchanged, so it's fully opt-in with zero regression.
Crucially, the shipped browser is a shell — the actual panes live on the pod and are loaded at render time, so adding a pane is "drop a file on your pod," never "fork the shipped file."
Upstream surface (small + stable)
- New file
data-browser-panes.js — sibling browser. It reuses the folder/JSON rendering and adds pane resolution: read the #dataisland resource, match the primary subject's @type, and render a pane (collapsible Source underneath); containers and unknown types fall back exactly like the folder browser.
- Widen the existing
--browser switch to accept panes:
index.js — allow panes in the validation (currently json | folder).lib/start.js — add panes to the browserFile map.
That's the whole upstream change. After it lands, all pane churn is local — upstream stays stable.
Local augmentation (your pod)
data-browser-panes.js discovers and loads pod-local panes from /public/panes/ (e.g. bookmark.js, tracker.js).- Each pane follows the losos pane contract (
canHandle / render keyed on @type local name).
- Add a pane → drop a module under
/public/panes/ → it renders. No fork, no republish.
First panes to ship as references: bookmark:Bookmark → card, wf:Tracker → task list.
Selecting it before publish
Until jspod publishes data-browser-panes.js, "select locally" means pointing the pod at a local copy of the shell (a transient --mashlib-module override). Once published, --browser panes resolves to the cdn copy by default and the override is removed.
Security note (for later, not this issue)
The shell loads pane JS from the pod being viewed — safe for your own pod, but rendering a foreign pod would execute that pod's JS. For cross-pod viewing, panes should come from a trusted registry keyed by @type, and data-declared views should be sandboxed/opt-in. Out of scope here; tracked separately when cross-pod rendering lands.
Done when
Supersedes #68 (which folded panes into the default folder browser via a node_modules override — replaced by the cleaner opt-in design below).
Idea
Add a third selectable data browser alongside
data-browser.js(json) anddata-browser-folder.js(folder): a pane-aware browser, chosen with the existing switch as--browser panes. The two existing browsers stay byte-for-byte unchanged, so it's fully opt-in with zero regression.Crucially, the shipped browser is a shell — the actual panes live on the pod and are loaded at render time, so adding a pane is "drop a file on your pod," never "fork the shipped file."
Upstream surface (small + stable)
data-browser-panes.js— sibling browser. It reuses the folder/JSON rendering and adds pane resolution: read the#dataislandresource, match the primary subject's@type, and render a pane (collapsible Source underneath); containers and unknown types fall back exactly like the folder browser.--browserswitch to acceptpanes:index.js— allowpanesin the validation (currentlyjson | folder).lib/start.js— addpanesto thebrowserFilemap.That's the whole upstream change. After it lands, all pane churn is local — upstream stays stable.
Local augmentation (your pod)
data-browser-panes.jsdiscovers and loads pod-local panes from/public/panes/(e.g.bookmark.js,tracker.js).canHandle/renderkeyed on@typelocal name)./public/panes/→ it renders. No fork, no republish.First panes to ship as references:
bookmark:Bookmark→ card,wf:Tracker→ task list.Selecting it before publish
Until jspod publishes
data-browser-panes.js, "select locally" means pointing the pod at a local copy of the shell (a transient--mashlib-moduleoverride). Once published,--browser panesresolves to the cdn copy by default and the override is removed.Security note (for later, not this issue)
The shell loads pane JS from the pod being viewed — safe for your own pod, but rendering a foreign pod would execute that pod's JS. For cross-pod viewing, panes should come from a trusted registry keyed by
@type, and data-declared views should be sandboxed/opt-in. Out of scope here; tracked separately when cross-pod rendering lands.Done when
data-browser-panes.jsshell (folder/JSON + pane resolution + loads/public/panes/)--browser paneswired (index.jsvalidation +start.jsmap)/public/panes/--browser panes(DOM-shim + live pod)