Core Concepts

Browser Physics

Flux treats the browser as a small physical system rather than a request-response terminal: state has inertia, mutations have momentum, and every open tab lives in the same field. This page names the five properties that govern how data behaves once it enters that system, and how they fit together into one consistent model.

Five properties, one system

A typical web app treats every piece of state as if it appeared from nothing the moment a request resolves, and disappeared the moment the tab closed. Flux doesn't model data that way. Once a piece of state is registered, it behaves according to a small, consistent set of physical properties — the same five, regardless of whether the data is a homepage, a dashboard metric, or a queued form submission.

None of these are separate features you turn on. They're properties every registered channel already has, in the same way a physical object already has mass before anyone measures it.

Inertia — data at rest stays at rest

A page that has been visited once carries weight. It doesn't need to be re-fetched to reappear — it resists disappearing, the same way a stationary object resists being moved. A returning visitor sees their dashboard, their catalog, their last-read article the instant the tab opens, without waiting on a network round trip to prove the data is allowed to exist again.

Inertia has a lifespan, not permanence — old data eventually goes stale and quietly refreshes itself in the background rather than blocking what's already on screen. The user experiences continuity, never a blank slate followed by a flash of content.

Momentum — a write in motion stays in motion

When a user submits something, that action doesn't require an unbroken network connection to complete — it carries its own momentum forward. Losing connectivity mid-submission doesn't cancel the write; it just changes the medium it's traveling through until it can land. The user's intent keeps moving even when the network temporarily can't carry it.

This is why closing a laptop lid mid-edit, or submitting a form in a subway tunnel, produces the same outcome as submitting it on perfect Wi-Fi — just delayed, never lost.

Damping — motion that would overshoot gets absorbed

Left alone, momentum can overshoot — fifty keystrokes want to become fifty requests, a nervous double-click wants to become two submissions. Damping is what absorbs that excess energy before it leaves the device: rapid, redundant motion gets smoothed into the single write the user actually intended, rather than amplified into a pile of duplicate ones.

Damping is tunable per interaction — a chat message and an autosaving text field don't want to be damped the same way, and Flux lets each channel decide how much of its own motion to absorb versus let through untouched.

Field — every open tab shares the same state, without a shared connection

State in Flux doesn't live locally to one tab the way it would in a plain in-memory store. It behaves like a field — a change anywhere is felt everywhere, across every open tab on the same origin, without every tab needing its own live connection to produce that effect. One tab can hold the actual connection to the outside world; the rest simply exist inside the field it maintains.

This is also why the server never sees N connections for N open tabs. The field has one source, not one source per observer.

Equilibrium — every path in settles to the same state

Data can reach your UI from a cold cache, a live update, or a fresh network response — three different origins. Equilibrium is the guarantee that it doesn't matter which one delivered it: all three settle into the exact same final state, through the exact same rules, every time. Your components never need to ask which path a piece of data took to get there.

This is what makes the previous four properties safe to rely on simultaneously — inertia, momentum, damping, and field effects could each individually introduce inconsistency, but equilibrium is the property that guarantees they never do, no matter how they overlap in a single moment.

The reason to name these five properties at all, rather than just listing features, is that they compose. A dashboard that's offline-edited by a user in one tab, while a second tab is open, while a background job is mid-flight, is exercising all five properties at once — and the guarantee across all of them is the same: nothing is lost, nothing arrives twice, and nothing shown to the user is ever a half-applied mix of two different states.

The one law underneath all five

Nothing a user does inside a Flux-registered channel is ever silently thrown away. It is cached, queued, shaped, merged, or resolved — but a real user action never simply vanishes because the network wasn't there to receive it. That single guarantee is what the rest of this page is describing from five different angles.

Each property maps to a concrete mechanism documented elsewhere — see core-concepts/5-layer-stack for how inertia and momentum are actually implemented, core-concepts/mutation-pipeline for damping, and core-concepts/activity-bus for how the field stays synchronized without racing itself during a reconnect.