Latency
Quiet when it is fast
It learns how long reads and saves usually take, separately for each. An answer that arrives quickly gets no ceremony. A slow one gets visible feedback, then context, then a way to stop waiting.
Alive States · prototype 0.3
Alive States keeps track of what is true in an interface: what the server confirmed, what is still in flight and what failed. It never shows a request as saved before the server says so.
What it decides
The same action can deserve a different response depending on how long it usually takes, whether the device is online, and how much a mistake would cost.
Latency
It learns how long reads and saves usually take, separately for each. An answer that arrives quickly gets no ceremony. A slow one gets visible feedback, then context, then a way to stop waiting.
Connection
It reads online and offline status and slow-connection hints when the browser offers them. Work done offline is kept on the device and marked as waiting. It is not dropped or reported as saved.
Risk
A reversible action may show its new value at once, marked as unconfirmed. A sensitive action waits for explicit confirmation and keeps the last confirmed value until the server answers.
The lifecycle
Alive States is the single source of truth for data and operations. LavaMorphism never decides an outcome: its surfaces only react to the phase Alive States reports.
| Phase | What it means | LavaMorphism shows |
|---|---|---|
| unavailable | No data yet. Nothing is invented. | Idle. Matte obsidian. |
| cached | The last confirmed data, from an earlier read. | Idle. Obsidian at rest. |
| fresh | Just read from the source. | Settled. Obsidian. |
| optimistic | A save is in flight and the new value is visible, marked unconfirmed. | Pending. Mercury flows out from where you acted. |
| syncing | A save is in flight and the confirmed value stays visible. | Pending. Mercury, with the confirmed value in place. |
| offline | No connection. The work is kept on the device. | Queued. Mercury pools and waits. |
| confirmed | The server confirmed. | Ember sweeps across for about a second, then obsidian. |
| failed | The server refused. The confirmed value returns and the draft is kept. | Failed. Mercury drains away. |
Past the usual time for that action, a pending phase becomes slow and the mercury stalls. If two versions disagree, the front wavers halfway until you choose one.
Where it runs
In BetterGains, editing the calories of a logged meal runs on Alive States: the card keeps its identity, the draft stays apart from the confirmed value, and a rejected or stale response cannot overwrite what you typed.
Try the same logic in the labThe SDK
Components for a boundary, a card, a value and a layout transition, plus hooks and reusable policies. The core reducer takes plain events:
let state = initialState(lastConfirmed)
state = aliveReducer(state, {
type: 'WRITE', id, next,
optimistic: risk !== 'high',
})
// only after a validated, successful response:
state = aliveReducer(state, {
type: 'RESOLVE', id, data: serverData,
})
Prototype 0.3 · local package, not on npm yet
Haptics are optional and off by default. Reduced motion is respected.