kristianwindandClaude Opus 4.8
57689ddfbb
The service worker did Web Push and nothing else, with a note that a cache serving yesterday's data was worse than an honest "cannot connect". This adds a cache that does not do that: network-first for everything that can go stale, so a reader online always gets the live answer and the cache is reached only when the network cannot answer. The task and note lists stay live; they just no longer go blank the moment the signal does — a reload through a tunnel, a lift or a base-station handover comes back to the app instead of the browser's offline page. Writes are untouched and still go straight to the network; api.js already retries them across the same short drop. The shell cache is versioned so a deploy lands in a fresh cache and the old one is dropped on activate; the data cache is cleared on sign-out so the next person on the browser does not inherit it. The old hand-registered /sw.js becomes SvelteKit's src/service-worker.js, which it registers itself, and the push handlers move across unchanged. Co-Authored-By: Claude Opus 4.8 <[email protected]>
web
The SvelteKit PWA. Not written yet — this directory holds its place so the Docker build has something to copy, and so the frontend stage can tell "not built yet" apart from "the build failed".
The Dockerfile builds this directory when it finds a package.json here, and
otherwise emits a placeholder page. So adding the real app is exactly: put a
SvelteKit project in this directory whose npm run build produces build/.
What it needs to be
- SvelteKit,
adapter-static, output inbuild/. The Go binary embeds that directory at compile time and serves it, falling back toindex.htmlso client-side routes survive a reload. - A PWA: installable, offline reading of already-cached lists, swipe gestures for complete and schedule.
- Nordic minimalism. Dark by default, light available. One accent colour, everything else neutral. Runic mark for Verdande.
- Optimistic on every local action. No spinner ever appears for something the browser could already know the answer to.
Talking to the backend
Same origin — the Go binary serves both. /api/v1 for REST, /api/v1/ws for the
live sync. Session cookie is httpOnly, so the frontend never handles the token
itself.
During development, run the backend on 8080 and point the Vite dev server's proxy at it:
VERDANDE_DATA_DIR=./data VERDANDE_DEV=true go run ./cmd/verdande