State Management

Where state lives

• Local state is variables inside a function. It is gone when the function returns.
• In-memory application state is objects and caches in a running process. It is lost on restart and not shared between several instances.
• Persistent state (databases and files) survives restarts.
• Client-side state includes cookies, browser storage, tokens and the screen the user sees.
• Session state is data tied to one user’s visit. HTTP itself is stateless, so servers link requests together with cookies or tokens.

Rules for handling state

• Keep state small and close to where it is used. Global, shared, changeable state is the hardest to reason about.
• Keep one source of truth. If the same fact is stored in two places, they will eventually differ. Derive the second from the first, and treat copies and caches as disposable.
• Prefer immutable data. Create a new value instead of changing the old one, and no other part of the program can be surprised by it.
• Make changes explicit. Update state through a few named functions or events.
• Model states and transitions. An order that is created, paid, shipped or cancelled is a small state machine. Listing the allowed transitions catches impossible combinations.

// JavaScript: mutating vs creating a new value
cart.items.push(item);                       // changes shared state in place
const newCart = { ...cart, items: [...cart.items, item] };   // leaves the old one untouched

Stateless services

Servers that keep no user data between requests can be copied, restarted and load-balanced freely, because any instance can handle any request. The state is moved to a database, a cache or the client. See Distributed Systems Basics.

Common state bugs

• Stale state: a cache or screen shows old data after the source changed.
• Race conditions: two actors change the same state at once. See Concurrency and Parallelism.
• Hidden state: behaviour depends on a global, a file or a setting nobody mentioned, so a bug cannot be reproduced.
• Unwanted persistence: sensitive data left in browser storage or logs.

Front-end frameworks come with their own state libraries. The same rules apply to them.

Try it

Pick a small feature you know, such as a login form or a shopping cart. List every piece of state it uses, where each lives, and who can change it. Mark any fact that is stored twice.