Two users editing the same file online could silently clobber each other:
the editor's save did a bare PUT with no precondition, even though the master
already enforces optimistic concurrency (fileapi.go checkIfMatch → 412). Now
the editor sends a precondition and surfaces a conflict UI instead of
overwriting.
- util.js: saveFile(node, content, contentType, opts) sends `If-Match: <etag>`
(or `If-Unmodified-Since` fallback) unless opts.force; returns {etag} from
the PUT response (so save→edit→save adopts the new version and doesn't
false-conflict); throws ConflictError (.status===412) on a precondition
failure so callers branch cleanly. New saveCopy() parks a conflicting edit
as `<stem>-conflict-<ts>.<ext>` (collision-probed) without losing either side.
- preview.js: getContentWithVersion(node) → {buf, etag, lastModified} captured
from the content GET (the listing JSON carries no per-file etag); threaded
into the editor ctx and exported. getArrayBuffer left untouched.
- conflict.js (new): shared, callback-driven dialog — mine-vs-theirs diff
(reuses zddc.diff + css/history.css) + Overwrite / Reload-theirs /
Save-a-copy / Cancel. Never calls saveFile/showFilePreview itself, so the
deferred Phase 5 cache-outbox conflict UI can reuse it with its own callbacks.
- preview-markdown.js / preview-yaml.js: capture + forward the version token,
adopt the returned etag on success, and on 412 open the dialog (Overwrite
re-fetches the current etag then re-saves — re-conflicts on a third writer
rather than blind-forcing; Reload clears dirty first so the renderInline
guard skips its confirm). FS-Access mode sends no precondition (no
concurrency) and never conflicts.
- build.sh: concat conflict.js after util.js.
- tests/conflict.spec.js (+ playwright project): If-Match sent, ConflictError
on 412, new-etag returned, force omits the precondition, dialog renders the
diff and each action resolves via its callback. Drives the fresh dist build
over file:// with a stubbed fetch (the test binary embeds the committed
browse.html, not dist, so a server-mode E2E would run stale code).
All browse + diff + conflict specs pass (18).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| css | ||
| js | ||
| build.sh | ||
| README.md | ||
| template.html | ||
browse — directory listing tool
Generic file browser for any directory. Designed to work with ZDDC archives but useful for any folder. Single-file HTML, no install.
How it's used
Two modes, auto-detected at page load:
-
Online (zddc-server backed). When this HTML is served by zddc-server at a folder URL — which it is by default for any directory under
ZDDC_ROOTthat doesn't have anindex.html— the JS queries the same URL withAccept: application/jsonto load the directory's listing and renders it as a sortable, filterable table. -
Local (FileSystemAccessAPI). Click "Select Directory" in the header to pick any folder on your computer. Works in Chromium-based browsers (Chrome, Edge, Brave, etc.). No server required; the directory is read directly from disk.
What it does
- Lists files and folders with name, size, type (extension), and modified date.
- Click a folder to expand inline. Children load lazily on first expand.
- Click a column header to sort by that column. Click again to reverse.
- Type in the filter to narrow to entries whose name contains the substring.
- Click any file to open it in a new tab — for server-backed pages,
this routes through zddc-server's normal handler (so an
.archiveredirect, an apps cascade override, etc. all work as expected).
Design notes
- No ZDDC-specific filtering. This tool is intentionally
domain-agnostic. The companion
archivetool layers ZDDC parsing (project / status / revision filters, tracking-number resolution) on top of the same listing API. Usearchivewhen you want ZDDC semantics; usebrowsewhen you just want to see what's in a folder. - Default at directory URLs. zddc-server's
directory.goserves the embedded browse.html bytes for any directory request withAccept: text/htmland noindex.htmlpresent. This means a user navigating to any folder underZDDC_ROOTgets a usable browser without anyone having to drop a file into the archive. - Apps cascade override. Like every other ZDDC tool, the
served
browse.htmlcan be overridden per-folder via a.zddc apps:entry. The default is the embedded copy from the binary; operators can pin a specific version or URL if they want.