Chapter 5

State Has an Address

If you can't point to where the state lives, you can't know what the state is.
Demo: User updates their email: where does the change propagate?
☠ React + Redux: 6 state locations
Redux Storeuser@old.com
Component Stateuser@old.com
Form Input Valueuser@old.com
URL Search Params?email=user@old.com
localStorageuser@old.com
Derived / Memoizedgreeting: Hello user@old
Propagation trace
✦ HTMX: 1 state location
Server-rendered DOMuser@old.com
Propagation trace
0
State locations
0
State locations
0
Stale copies
0
Stale copies

What you just saw

The left panel is a React/Redux application. The user's email address lives in six places: the Redux store, component local state, the form input's value, URL search params, localStorage, and a memoized derived value. When the user updates their email, the change propagates through dispatch, reducers, selectors, and side effects. Each location updates at a different time. Between updates, some locations hold the old value while others hold the new value. The application is in an inconsistent state until all six locations have been updated, and there is no single point where you can verify they agree.

The right panel is an HTMX application. The user submits the form. The server processes the change and returns new HTML. The browser swaps the HTML into the DOM. The email address lives in one place: the DOM, as rendered by the server. There is nothing to synchronize because there is only one copy.

How this works: This demo visualizes state fragmentation, not timing. The dishonest side scatters the same value across six locations that must be kept in sync. The honest side stores it once. Counts are architectural facts, not nanosecond measurements. Source: github.com/adamzwasserman/honest-code-traces
← Ch.4: Pure Functions Ch.6: Declare, Don't Instruct →