foldkit-mirror

Keeps part of a Foldkit Model represented somewhere else — usually the URL or a key-value store — without making that representation the owner of the state.

A filter can become ?filter=active; a draft can survive a reload; a collapsed sidebar can be remembered. In every case the Model remains authoritative and update remains the only place application state changes.

The mental model is:

Model slice
   |
   | encode when it changes
   v
URL / KeyValueStore

URL / KeyValueStore
   |
   | decode on navigation / cold load
   v
Model slice

A mirror is therefore a secondary representation, not a second store of truth.

Use it for disposable, per-device state that is cheap to lose: filters, sort, page, open panels, preferences, drafts, and similar local state. Do not use it for state that several clients must converge on. A mirror is last-write-wins with no durable log or ordering.

That is the boundary between the three nearby packages:

Mirror
  Model owns the value
  URL / store represents it
  losing the representation is acceptable

Sync
  client-authored state must survive offline
  durable operations replay and converge

Remote
  server owns the fact
  client Model caches a disposable copy

Which state belongs here?#

A useful rule across Foldkit Plus remains one owner per datum. A mirror observes a local field; it does not claim that field.