The Map Stores Nothing of Its Own

"The map stores nothing of its own."

The Purest Projection in the System

The Map is the clearest example of the whole track's discipline, because it owns absolutely no data. It reads the captured and intended locations already on the crumbs, draws them as points, and holds nothing else. There is no 'map database', no cached pin table, no separate copy of where things are. Move a crumb, re-file it, correct its intended location, and the Map simply reflects the change on its next read — because it never had its own version to fall out of sync. The Map is a lens, and a lens stores nothing; it only bends light from the one thing that's really there.

Concretely it's MapLibre GL over an open tile source, with the two-truth precedence you already know — intended location first, captured second — and it's coordinates-first: Vesta's location is points, not place-name geocoding. But the architecture that matters is the boundary: every point the Map shows comes from the crumb store, and nothing the Map does writes back to it. A crumb with no location simply doesn't appear; the Map invents nothing.

The safest view is the one that owns no data. A projection that stores nothing can never drift, never needs migrating, never contradicts the source, and can be deleted without losing anything. When you can express a view as a pure read over the canonical store, do — you get correctness for free and pay no ongoing cost to keep it consistent. Storage in a view is a liability; the less a lens owns, the more trustworthy it is.

Lazy by Construction: the Map Never Taxes Capture

Owning no data also lets the Map stay out of the way of the thing that matters most — capture. The map library and its tiles are lazily chunked, so opening the app to drop a crumb never downloads a map you didn't ask for. The capture path stays feather-light; the geographic projection loads only when you actually go look at it. This is the one-store discipline paying a second dividend: because the Map is a self-contained lens that reads on demand, it can be deferred entirely, and the five-second capture loop never carries its weight.

Why Adding a Projection Stays Cheap

Step back and the whole track resolves into one property: because there is a single canonical store and every view is a read over it, adding a new way to look is cheap by construction. Want a heatmap of where you write most, a word-frequency view, a stats page of crumbs-per-month? Each is a new query over the same crumbs — a new lens, not a new store. It can't create a second source of truth, can't drift, and can be added or removed without touching the data. That is the quiet superpower of one-state-many-projections: the model stays small and canonical, while the number of ways to see it can grow without bound, each one free of the synchronization tax that a copy-per-view design would charge on every write.

Code

The Map: a pure read, deferred until opened·typescript

// the Map owns NO data — it reads crumbs and draws points
function mapPoints(crumbs: Crumb[]): Point[] {
  return crumbs
    .map(c => c.intended_location ?? c.captured_location) // precedence
    .filter(Boolean)                                       // no loc -> no point
    .map(toPoint);
  // nothing is written back; a crumb with no location simply isn't shown
}

// lazy-chunked: the capture path never pulls the map library/tiles
const Map = lazy(() => import("./MapView")); // loads only when you open Map

// adding a projection = another pure read, never a new store:
const heatmap = crumbs => bucketByWeek(crumbs);   // free to add, free to drop

Exercise

Audit the views in a system you know and label each: does it own stored data, or is it a pure read over a canonical source? For any view that owns a copy, ask what it would take to make it a pure projection instead, and what class of sync bug you'd retire. Then imagine adding a brand-new view — is that cheap (another read) or expensive (another store to keep in sync)? The answer tells you how healthy the model is.

Hint

Pure-read views are the healthy ones: no drift, no migration, deletable without loss. A view that owns a copy is a liability with an ongoing sync cost. The tell for a good model is that adding a new way to look is trivial — if every new view means another store to synchronize, the canonical-store discipline has been lost somewhere upstream.

The Map Stores Nothing of Its Own

The Purest Projection in the System

Lazy by Construction: the Map Never Taxes Capture

Why Adding a Projection Stays Cheap

Code

External links

Exercise

Progress

Comments 0