"State is your app's memory — what's logged in, what's in the cart, what the balance is. Managing it well is what keeps an app from getting confusing."
Learning Objectives
By the end of this module, you will be able to:
- Explain what "state" means in an app
- Keep a single source of truth
- Update the UI when state changes
- Avoid common state bugs
1. What Is State?
State is the data your app holds right now: the logged-in user, their account balance, items in a cart, whether a menu is open. As users act, state changes — and the screen should reflect it.
It helps to separate two things in your mind: the data (state) and the display (UI). The data is the truth; the display is just a picture of that truth at a moment in time. A shopping cart "has three items" whether or not the little badge in the corner shows "3" — the badge is only there to reflect the underlying number. Even something as small as whether a dropdown is open or closed is a piece of state.
Key idea: Keep a single source of truth — one place that holds the current data. When something needs to change, update that one place, then refresh the UI from it. This prevents the classic bug where two parts of the screen disagree.
Explain like I'm new: State is like the score in a game written on one scoreboard. Everyone looks at that one board. If you also scribbled the score on sticky notes around the room, they'd soon disagree — and nobody would know the real score.
2. The State → UI Pattern
The reliable rhythm (you saw a mini version in Module 13):
change the state → re-render the UI from the state
[object Object], account = { ,[object Object],: ,[object Object],, ,[object Object],: ,[object Object], }; ,[object Object],
,[object Object], ,[object Object],(,[object Object],) { ,[object Object],
nameEl.,[object Object], = account.,[object Object],;
balanceEl.,[object Object], = account.,[object Object],;
}
,[object Object], ,[object Object],(,[object Object],) {
account.,[object Object], += amount; ,[object Object],
,[object Object],(); ,[object Object],
}Read the deposit function closely: it never touches the screen directly. It changes the data (account.balance), then calls updateUI() to redraw from that data. This one-way flow — data first, display second — is the single most important habit in modern front-end development, and it's the same idea powering frameworks like React and Vue.
The banking project keeps the account in one object and re-renders whenever it changes — login, balance, transactions all flow from that single state.
Concept: Because the UI is always drawn from the state, you never have to ask "is the screen up to date?" You just change the data and re-render. The display can't drift out of sync because it has no memory of its own.
3. Where to Keep State
- In memory (a variable/object) — for the current session
- In local storage — to survive a page refresh (Module 15)
- On the server — the real, permanent source (via APIs)
Most real apps use all three at once: the server holds the permanent truth, local storage keeps a copy so a refresh doesn't log you out, and an in-memory object holds the version your code reads and writes moment to moment. Deciding where a piece of state belongs is half the job: ask how long it needs to live and who else needs to see it. A theme setting can happily sit in local storage; a bank balance must come from the server.
Real-world use case: When a shopping site remembers your cart after you close the tab and return, that's state saved in local storage or on the server. When the cart empties the instant you refresh, it was living only in memory.
Beginner mistake: Storing the same fact in several places and updating them separately. They drift out of sync and the UI shows contradictions. Keep one source of truth and always render from it.
Practice task: Build a tiny cart: an array cart = [], an "add item" button that pushes to it, and a display that re-renders the count from cart.length every time. Notice you only ever change the array — the UI just follows.
Key Takeaway: State is your app's current data. Keep a single source of truth, and follow the pattern change state → re-render UI from state (as the banking project does). Store state in memory, in local storage to survive refreshes, or on the server for permanence — but never let the same fact live in two places that can disagree.
Further Learning
Adapted from Microsoft's Web Dev for Beginners (MIT License). Bank project from the source curriculum.