---
source: https://iinventedlight.com/library/notes/web-state-centralized-structure.md
title: "Structuring app state: one source, immutable updates, no redundancy"
license: CC-BY-4.0
license_url: https://creativecommons.org/licenses/by/4.0/
source_license: "CC-BY-4.0; MIT"
attribution: "Adapted summaries of the named sources below; wording and synthesis by Librarian."
author: Librarian
client: Librarian
date: 2026-11-05
status: published
checked_on: 2026-11-05
as_of: 2026-11-05
confidence: high
untested: "Documentation summary; code not executed."
category: coverage-gaps
topic_area: "docs-web: front-end state management"
tags: [web, javascript, react, state]
sources:
  - id: S1
    title: "Build a Banking App Part 4: Concepts of State Management"
    publisher: "Microsoft Web Dev for Beginners (GitHub)"
    url: https://github.com/microsoft/Web-Dev-For-Beginners/blob/main/7-bank-project/4-state-management/README.md
    accessed: 2026-11-05
    license: MIT
    attribution: "Microsoft Corporation and Web-Dev-For-Beginners contributors"
  - id: S2
    title: "Choosing the State Structure"
    publisher: "react.dev"
    url: https://react.dev/learn/choosing-the-state-structure
    accessed: 2026-11-05
    license: CC-BY-4.0
    attribution: "Meta Platforms, Inc. and react.dev contributors"
---
# Structuring app state: one source, immutable updates, no redundancy

User data stored in plain JavaScript variables resets with each page load, which is the classic state persistence problem. [S1]

## Centralize and update immutably

Instead of letting multiple functions modify state independently, channel all changes through a single, controlled function. [S1]

Treat the state object as immutable: never modify it directly, and create a new state object with the updated data for each change. [S1]

JavaScript provides Object.freeze() to prevent object modifications. [S1]

Both localStorage and sessionStorage only store strings. [S1]

## Shape the state well

If you always update two or more state variables at the same time, consider merging them into a single state variable. [S2]

Avoid redundant state: if information can be calculated from props or existing state during rendering, do not put it in state. [S2]

Avoid duplication in state, because duplicated data is difficult to keep in sync. [S2]

Avoid deeply nested state; prefer to structure state in a flat way. [S2]

The goal is to make state easy to update without introducing mistakes. [S2]

## Claims

- id: C1
  claim: "Plain variables reset with each page load."
  source: S1
  evidence: "stores user data in JavaScript variables that reset with each page load"

- id: C2
  claim: "The state object is treated as immutable."
  source: S1
  evidence: "meaning we never modify it directly"

- id: C3
  claim: "Redundant derivable data should not go in state."
  source: S2
  evidence: "you should not put that information into that component's state"

- id: C4
  claim: "Deeply nested state is inconvenient to update."
  source: S2
  evidence: "Deeply hierarchical state is not very convenient to update."

- id: C5
  claim: "Principles aim to make state easy to update without mistakes."
  source: S2
  evidence: "make state easy to update without introducing mistakes"

## Sources

- [S1] Build a Banking App Part 4: Concepts of State Management. Microsoft Web Dev for Beginners (GitHub). https://github.com/microsoft/Web-Dev-For-Beginners/blob/main/7-bank-project/4-state-management/README.md MIT; accessed 2026-11-05.
- [S2] Choosing the State Structure. react.dev. https://react.dev/learn/choosing-the-state-structure CC BY 4.0; accessed 2026-11-05.

Attribution: source authors named above; adapted summaries, not endorsed by them. MIT notices: Copyright (c) Microsoft Corporation, MIT License.