State management

State is data that changes over time

A JavaScript app is easy while all data lives in one function call. It becomes harder when the same user action affects the header, a form, a URL, cached server data, and a result panel. State management is the discipline of naming the owner of each changing value and making updates predictable.

State is not only a global store. It can be local UI state, server/cache state, URL state, or a form draft. The trick is choosing the smallest reliable owner. The next lesson on app architecture connects those owners to components and boundaries; this lesson stays focused on state itself.

Compute derived state instead of storing two truths

A common bug is storing both cart.items and cartItemCount. Remove an item and forget to update the count, and the header disagrees with the cart list. Store the source data; compute the count and total when you need them.

1const cart = [2  { name: "Tea", price: 12, qty: 2 },3  { name: "Mug", price: 5, qty: 1 },4];5 6const itemCount = cart.reduce((total, item) => total + item.qty, 0);7const total = cart.reduce((sum, item) => sum + item.price * item.qty, 0);8 9console.log(itemCount);10console.log(total.toFixed(2));

Line 1 stores the source array. Lines 6 and 7 derive facts from that array. If the cart changes, re-running those expressions produces fresh values without syncing a second field.

A store is just an object with a few promises: it owns the current state, readers can subscribe, and writes go through dispatch. The subscription idea is related to the observer pattern, but here the main point is that subscribers do not own their own cart copies.

1function createStore(reducer, initialState) {Run2  let state = initialState;3  const listeners = new Set();4 5  return {6    getState() {7      return state;8    },9    subscribe(listener) {10      listeners.add(listener);11      return () => listeners.delete(listener);12    },13    dispatch(action) {14      const previousState = state;15      state = reducer(state, action);16      if (previousState !== state) {17        listeners.forEach((listener) => listener(state, action, previousState));18      }19      return action;20    },21  };22}23 24function cartReducer(state, action) {25  switch (action.type) {26    case "cart/add":27      return { ...state, items: [...state.items, action.payload] };28    default:29      return state;30  }31}32 33const store = createStore(cartReducer, { items: [] });34const unsubscribe = store.subscribe((state, action) => {35  console.log(action.type + ": " + state.items.length);36});37 38store.dispatch({ type: "cart/add", payload: { id: "tea", name: "Tea" } });39unsubscribe();40store.dispatch({ type: "cart/add", payload: { id: "mug", name: "Mug" } });41console.log(store.getState().items.map((item) => item.id).join(", "));

Read the step-through like a loop: dispatch(action) sends a fact, the reducer returns the next state, the store replaces its snapshot, and subscribers update their views. The unsubscribe function is just as important as subscribe, because removed UI should stop listening.

A reducer is a pure function: (state, action) => nextState. The action is plain data such as { type: "cart/add", payload: item }. The reducer should not fetch, write web storage, mutate its input, or depend on time. That is exactly why the pure functions lesson matters here.

Action creators are tiny helpers that return those action objects. Slice reducers keep unrelated areas separate: a cart reducer updates cart items, a UI reducer updates whether the cart drawer is open, and a root reducer combines them.

1const addItem = (item) => ({ type: "cart/add", payload: item });2const toggleCart = () => ({ type: "ui/toggle-cart" });3 4function cartReducer(state = { items: [] }, action) {5  if (action.type === "cart/add") {6    return { ...state, items: [...state.items, action.payload] };7  }8  return state;9}10 11function uiReducer(state = { cartOpen: false }, action) {12  if (action.type === "ui/toggle-cart") {13    return { ...state, cartOpen: !state.cartOpen };14  }15  return state;16}17 18function combineReducers(reducers) {19  return (state, action) => {20    let changed = false;21    const next = {};22    for (const key of Object.keys(reducers)) {23      next[key] = reducers[key](state[key], action);24      changed = changed || next[key] !== state[key];25    }26    return changed ? next : state;27  };28}29 30const reducer = combineReducers({ cart: cartReducer, ui: uiReducer });31let state = { cart: { items: [] }, ui: { cartOpen: false } };32state = reducer(state, addItem({ id: "tea" }));33state = reducer(state, toggleCart());34console.log(state.cart.items.length);35console.log(state.ui.cartOpen);

Lines 1 and 2 build action objects. Lines 4 and 11 keep two slices independent. Lines 18 through 27 make a root reducer: call each slice, track whether any slice reference changed, and reuse the old root object when nothing changed.

JavaScript variables hold references to objects and arrays. The objects and references lesson explains why two names can point at the same object. State management uses that fact on purpose: when an update returns a new reference, prevState !== nextState is a cheap signal that something changed.

Copy only the path that changes. Use object spread from spread and rest, arrays like map and filter, and copying methods such as toSorted and with. Keep old snapshots and you get undo, replay, and time travel.

1const board = {2  user: { name: "Asha", badges: ["member"] },3  tasks: [4    { id: "draft", title: "Draft reducer", done: false },5    { id: "ship", title: "Ship lesson", done: false },6  ],7  priorities: ["low", "medium", "high"],8};9 10const nextBoard = {11  ...board,12  user: { ...board.user, badges: [...board.user.badges, "reviewer"] },13  tasks: board.tasks.map((task) =>14    task.id === "draft" ? { ...task, done: true } : task,15  ),16  priorities: board.priorities.with(1, "normal").toSorted(),17};18 19console.log(board.tasks[0].done);20console.log(nextBoard.tasks[0].done);21console.log(board.tasks === nextBoard.tasks);22console.log(nextBoard.priorities.join(", "));

Line 10 creates a new board. Line 12 copies a nested object and array. Lines 13 through 15 replace only the matching task. Line 16 uses copying array methods; the original priorities array is still available for history or comparison. For more patterns, see immutability.

1function createStore(reducer, initialState) {2  let state = initialState;3  const listeners = new Set();4 5  return {6    getState() {7      return state;8    },9    subscribe(listener) {10      listeners.add(listener);11      return () => listeners.delete(listener);12    },13    dispatch(action) {14      const previousState = state;15      state = reducer(state, action);16      if (previousState !== state) {17        listeners.forEach((listener) => listener(state, action));18      }19    },20  };21}22 23function badCartReducer(state, action) {24  if (action.type === "cart/add") {25    state.items.push(action.payload);26    return state;27  }28  return state;29}30 31const store = createStore(badCartReducer, { items: [] });Run32const renders = [];33store.subscribe((state) => {34  renders.push("rendered " + state.items.length);35});36 37store.dispatch({ type: "cart/add", payload: { id: "tea" } });38console.log(renders.length);39console.log(store.getState().items.length);

The mutation lab is the bug in slow motion. The cart really changes, but the outer state reference does not. A subscriber or UI selector that relies on reference equality can skip the update and display stale information.

1const template = {2  user: { name: "Asha" },3  created: new Date("2026-09-26T00:00:00Z"),4};5 6const copy = structuredClone(template);7copy.user.name = "Mina";8 9console.log(template.user.name);10console.log(copy.user.name);11console.log(Object.prototype.toString.call(copy.created));

structuredClone is useful for deep-copying many data values, including Dates. It can throw for functions and DOM nodes, and cloning a whole state tree can do far more work than a targeted reducer copy. Preserve sharing when you can.

1// Conceptual Immer-style code. Immer is not installed in this lesson.2const nextState = produce(state, (draft) => {3  draft.cart.items.push({ id: "tea", name: "Tea" });4  draft.ui.cartOpen = true;5});

Immer-style libraries let you write draft mutations and produce immutable results. This is ergonomic, but the principle is the same: the committed state must be a fresh immutable snapshot. Immer is not installed in this lesson, so the block is marked as conceptual.

Reducers are good for data updates. State machines are better when a flow has named stages and invalid transitions. A request can be idle, loading, success, or error. It should not be both loading and success, and it should not submit again while already loading.

1const transitions = {Run2  idle: { SUBMIT: "loading" },3  loading: { RESOLVE: "success", REJECT: "error" },4  success: { RESET: "idle" },5  error: { RETRY: "loading", RESET: "idle" },6};7 8function transition(state, event) {9  const nextValue = transitions[state.value]?.[event.type];10  if (!nextValue) return state;11  return {12    value: nextValue,13    context: { ...state.context, lastEvent: event.type },14  };15}16 17let state = { value: "idle", context: { lastEvent: null } };18for (const event of [{ type: "SUBMIT" }, { type: "SUBMIT" }, { type: "RESOLVE" }]) {19  const next = transition(state, event);20  console.log(state.value + " + " + event.type + " -> " + next.value);21  state = next;22}

The interpreter is small: look up the event in the transition table for the current state. If no transition exists, return the current state. Larger statecharts add hierarchy, parallel states, guards, and effects. Libraries such as XState package those ideas, but you can learn the core with this tiny interpreter.

The first question is not “Which library?” It is “Who owns this value?” A one-component tooltip should stay local. A server response should usually be cache state. A shareable filter belongs in the URL, which the URL objects lesson covers. A cart read by multiple features needs shared app state.

1const initialState = {2  todos: [{ id: "draft", text: "Draft reducer", done: false }],3  filter: "all",4};5 6function todoReducer(state, action) {7  switch (action.type) {8    case "todo/add":9      return { ...state, todos: [...state.todos, action.payload] };10    case "todo/toggle":11      return {12        ...state,13        todos: state.todos.map((todo) =>14          todo.id === action.payload.id ? { ...todo, done: !todo.done } : todo,15        ),16      };17    case "filter/set":18      return { ...state, filter: action.payload };19    default:20      return state;21  }22}23 24const selectOpenCount = (state) => state.todos.filter((todo) => !todo.done).length;25let state = initialState;26state = todoReducer(state, {27  type: "todo/add",28  payload: { id: "ship", text: "Ship lesson", done: false },29});30state = todoReducer(state, { type: "todo/toggle", payload: { id: "draft" } });31console.log(selectOpenCount(state));

The playground is small enough to read. Every button dispatches an action. The reducer returns a new snapshot. The action log and slider demonstrate why immutable state makes undo and time travel possible: old snapshots still mean what they meant when they were created.

1const preferences = { theme: "dark", sidebar: "open" };2localStorage.setItem("cf-preferences", JSON.stringify(preferences));3 4const restored = JSON.parse(localStorage.getItem("cf-preferences") ?? "{}");5const url = new URL("https://example.com/products?sort=price");6url.searchParams.set("page", "2");7 8console.log(restored.theme);9console.log(url.pathname + url.search);

Persistence is a storage choice, not a second owner. Use localStorage for private preferences that should survive reloads. Use the URL for state someone should be able to refresh, bookmark, or send to a teammate. The inline runner is sandboxed without storage access, so this browser API example is shown as a page-context fragment.

Common misconceptions

• “All state belongs in a global store.” Local UI toggles and temporary form drafts often belong close to the component that owns them.
• “If I store the count, the UI is faster.” Store source data and derive counts unless measuring proves the computation is expensive.
• “A reducer can mutate if the app still looks right.” Mutation breaks reference equality, undo, time travel, and skipped-render logic.
• “State machines are only for huge apps.” They are useful whenever a small flow has invalid transitions, such as submit while loading.
• “localStorage is state management.” Storage persists a snapshot. Your app still needs one owner and one update path after hydration.
• “Signals replace thinking about ownership.” Signals change how subscriptions are tracked; they do not decide what should be local, shared, cached, or URL-owned.

Notice how this lesson links to nearby patterns rather than duplicating them. The observer pattern handles subscriptions and signals in depth; app architecture handles MVC, components, and dependency injection; structural and behavioral patterns cover commands, strategy, and undo-friendly actions.

Key takeaways

• State is changing data that affects behavior or rendering; not all state is global.
• A single source of truth prevents two writable copies from disagreeing.
• Reducers take previous state plus an action and return the next state without side effects.
• Immutable updates make reference equality, undo, and time travel practical.
• State machines make finite flows explicit and block invalid events.
• Use localStorage for private persistence and the URL for shareable navigation state.

Up next: Structuring an application, where state choices meet components, MVC-style boundaries, and dependency injection.